From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

<keywords content="keywords"> errors, error, SOA layer, invocation, web service </keywords>

SOA Layer Issues

Error Handling in the Web Services Invocation

The SOA layer offers transactional features to the actions performed in the exposed services for error handling. Thus, an automatic rollback of the active transaction will be performed when data inconsistencies are detected during an insertion or update of entities. The rollback feature does not allow the storage of inconsistent information in the database.

The message of the generated exception will be found in the xml output when error or exceptions are thrown during the service invocation. The xml output will also show the section of the xml input document where the error occurred.

The xml output for those methods that perform insertions and updates along with the automatic case filing is displayed as follows.

Insertions in the related entity ClientVariableData is illustrated in the document below listed; however, a string is passed in the attribute idMaritalStatus corresponding to id of the parametric entity of integer type. This kind of data type correspondence errors are detected by the SOA layer, which is displayed in the xml output.

The error message includes the following tags:

<Node>: This tag shows the node number where the error was generated.

<Path>: This tag displays the path of the information in the xml document where the exception was generated; the root entity V_ClientRequest and idClientVariableData are displayed in the example.

<Atrib>: This tag refers to the processed attribute.

<Value>: The value to be assigned to the attribute in mention is contained in this tag.

<ErrorMessage>:The message of the generated exception is displayed in this tag.

Likewise, the tags below listed can be observed after the node <Error> is closed.

<V_ClientRequest> with values of 665 and 666, which means that the input document contained 3 nodes of which the first node generated the exception and the other two tags did not display any inconsistency during the data insertion; thus, those tags were successfully saved in the database and the keys generated for these nodes were 665 and 666 respectively. The information corresponding to the first node was not inserted for any of its levels because a rollback of the transaction was executed when the exception was launched.

The xml input document is presented to file the cases through the SOA layer; likewise, an integer field was placed in the character chain.

The output generated indicates the cause of the exception, the path, the evaluated attribute and its value. Additionally, the evaluated node that generates the error between tags <NodeInformation> is displayed; adding the key can enable this last feature.

<add key = "returnSoaNodeInfo" value = "0"/> in the web.config and setting its value to 1

Other Advantages of the Business Keys Use

The records ids must be known by the methods used to update entity attributes. Knowing whether the information exists in the Bizagi database can led to an inherent complexity. Based on this scenario, the SOA layer allows through the use of business keys to perform a search of the required record. The SOA layer inserts the record with the values provided when the record does not exist; otherwise, the record is updated with the respective values whether the business key is matched.

The client identification number is used as a business key in the xml document below listed. The SOA layer will perform a search restricted to the client identification number. The records will be updated whether one record matches the key and an error will be generated whether many records contain the same key. The record will be inserted when the key is not matched to any existing record. The xml output will return the surrogateKeyValue of the record for insertions or updates.

Knowing previously the parametric entities ids is required to insert, update and save the operations performed on the master entities. The business key can be an alternative when the parametric entities ids are unknown; for example, the short name for a national identity card can be C and unique for a parametric entity of document type. This criterion can be used to set the xml input and replace the Bizagi ids associated to the parametric data. An example of this situation is displayed as follows.

The values in the Client master entity are entered and the business key for the fields containing the parametric entity records ids are used, such as identification type, sex, and civil state. <comments />