ADUCID 4.x

User Tools

Site Tools

Trace:
nocode:transactions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
nocode:transactions [2019/08/13 05:02]
740803864 [Negative response] 		nocode:transactions [2020/03/29 11:34] (current)
77.75.78.163 ↷ Links adapted because of a move operation
Line 6: Line 6:
 See chapters below for details. See chapters below for details.
  
-===== Set up =====+===== Setup =====
 At first, transaction must be prepared and sent to ADUCID Binder. ADUCID Binder accepts transaction HTTP requests at ''/aducid-binder/prepareTransactionUpload''. Before ADUCID Binder call, **unique identifier (aka ''transactionId'') must be generated**. This identifier is neccessary to successfully pair transaction request and response. Let's see ADUCID Binder transaction interface parameters: At first, transaction must be prepared and sent to ADUCID Binder. ADUCID Binder accepts transaction HTTP requests at ''/aducid-binder/prepareTransactionUpload''. Before ADUCID Binder call, **unique identifier (aka ''transactionId'') must be generated**. This identifier is neccessary to successfully pair transaction request and response. Let's see ADUCID Binder transaction interface parameters:
 ^ Name ^ Values ^ Mandatory ^ Description ^ ^ Name ^ Values ^ Mandatory ^ Description ^
Line 16: Line 16:
 | udi | String | No | if defined, security attack check is realized | | udi | String | No | if defined, security attack check is realized |
 | peigId | String | No | if defined, mobile push notification is realized | | peigId | String | No | if defined, mobile push notification is realized |
-**It is neccessary to add ''transactionId '' parameter to ''redirectUrl'' attribute** to successfully pair transaction request and response. If ''errorPage'' is not defined, ''redirectUrl'' is used in case of error. Now we can send prepared request to ''/aducid-binder/prepareTransactionUpload'' and check successful transaction upload (HTTP code 200).+**It is neccessary to add ''transactionId'' parameter to ''redirectUrl'' attribute** to successfully pair transaction request and response. If ''errorPage'' is not defined, ''redirectUrl'' is used in case of error. Now we can send prepared request to ''/aducid-binder/prepareTransactionUpload'' and check successful transaction upload (HTTP code 200).
  
 We must also remember to provide generated transaction identifier to web view, e.g. Ajax JSON response or JSP expression language. We must also remember to provide generated transaction identifier to web view, e.g. Ajax JSON response or JSP expression language.
  
 ===== Transaction itself ===== ===== Transaction itself =====
-When transaction data are successfully uploaded, we can start transaction itself. It can be done with use of [[web-integration:client-side|Client API for Web Integration]]. We only need to specify ADUCID Binder methods to serve transaction:+When transaction data are successfully uploaded, we can start transaction itself. It can be done with use of [[web-integration:client-side|Client API for Web Integration]]. We only need to specify right ADUCID Binder methods to serve transaction:
  
 <code javascript> <code javascript>
Line 35: Line 35:
  
 ==== Positive response ==== ==== Positive response ====
-When transaction was successful, JSON response will be:+When transaction was successful (''status = OK''), JSON response will be:
  
 <code javascript> <code javascript>
Line 46: Line 46:
  
 ==== Negative response ==== ==== Negative response ====
-Transaction can be also unsuccessful. There are two types of failures - failure directly on AIM and second level failure. Failure on AIM can be:+Transaction can be also unsuccessful (''status = ERROR''). There are two types of failures - failure directly on AIM and second level failure. Failure on AIM can be:
  
 <code javascript> <code javascript>
Line 63: Line 63:
 </code> </code>
  
-In case of AIM failure, values ''statusAIM'' and ''statusAuth'' will be filled, ''statusLF'' only in case of personal code use. You can find ''statusAuth'' and ''statusLF'' meanings in chapter [[other:error-statuses|Error statuses of authentication process]]. Meanings of ''statusAIM'' describes [[other:aim-statuses|Semantics of individual statuses of the authentication session (AIMStatus)]] chapter. Attribute ''message'' is technical readable text describing error.+In case of AIM failure, values ''statusAIM'' and ''statusAuth'' will be filled, ''statusLF'' only in case of personal code use. You can find ''statusAuth'' and ''statusLF'' meanings in chapter [[settings-mgmt:20-error-statuses|Error statuses of authentication process]]. Meanings of ''statusAIM'' can be found in [[settings-mgmt:11-aim-statuses|Semantics of individual statuses of the authentication session (AIMStatus)]] chapter. Attribute ''message'' is technical readable text describing error.
  
 Secondary level failure can look like: Secondary level failure can look like:
Line 82: Line 82:
 </code> </code>
  
-In this case, value ''key'' is filled, ''arguments'' only in situation of existing error message arguments. Attribute ''message'' is technical readable text describing error.+In this case, value ''key'' is filled, ''arguments'' only in situation of existing error message arguments. Possible values of ''key'' can be found at [[https://wiki.aducid.com/client-api/com/aducid/sdk/enums/ClientStatus.html|Client Status]] or [[https://wiki.aducid.com/web-platform/com/aducid/web/enums/WebStatus.html|Web Status]]. Attribute ''message'' is technical readable text describing error.
  
nocode/transactions.1565672520.txt.gz · Last modified: 2019/08/13 05:02 by 740803864

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki