EAI plug-ins that support the Asynchronous With Reply call-out method can be utilized to increase the performance of processing complex procedures. Asynchronous with reply means that the call-out and reply is split into two operations. This means that multiple EAI call-outs can be made in parallel before asking for the replies.
When a reply to one of the asynchronous with reply call-outs is received for a step defined as immediate release, the actions of the EAI step are processed immediately. This is performed before waiting for replies to any other asynchronous with reply call-outs that are actions of the releasing EAI step.
The background process will check for other EAI steps on parallel workflow paths and call-out to these in parallel. The following procedure shows a series of steps in sequence that takes 7 seconds to complete (3 seconds to process step 1, followed by 2 seconds for step 2 and 2 seconds for step 3).
You can decrease the time this case takes by putting the EAI steps in parallel so that they are invoked at the same time. The following diagram shows how the procedure can be redesigned so that two EAI steps are processed in parallel and the procedure now takes only 5 seconds to complete (3 seconds for step 1 and 2 seconds for step 3; step 2 is simultaneously processed with step 1.)
You can set up a Straight Through Processing (STP) procedure by linking sequential EAI steps together. This type of procedure can be processed by iProcess with little or no user interaction and the entire procedure can be performed as one transaction. This type of procedure design can enable business processes to be completed very quickly so it can be useful for processes such as share trading, customer call center queries and financial transactions.
Because multiple iProcess background processes can be running, EAI steps can be used to directly call out to third party applications. Multiple EAI steps can be processed sequentially making processes faster to complete.
You can delay the release of an EAI step so that the external application releases the step at a later time or when it has completed its processing. For example, if an external database is awaiting some customer information, the step is not released until the database is updated. If this update takes a while, you can prevent the background process being blocked during this time by using delayed release.
Delayed release EAI steps do not immediately process their actions because iProcess saves the step as outstanding in the case information. The release can be triggered by the external application via TIBCO iProcess Objects calls or using the
Pstaffifc APPRELEASE command.
The TIBCO iProcess Modeler’s message queuing system ensures reliable delivery of iProcess messages, with transactional control and integrity provided by the underlying database resource manager.
|
|
See TIBCO iProcess Engine Architecture Guide for more information about the messaging system.
|
When, for example, a new case is started or a work item released, a message is enqueued to a message queue, containing the necessary instructions to process the transaction that forms the next step in the business procedure being executed. The message is dequeued from the message queue and processed by a
BG process, and only deleted from the message queue when the transaction has successfully completed. If the transaction fails and is rolled back, the message remains in the queue, to be retried later.
Configurable parameters define how many times the message will be retried, and the delay between each attempt. If the retry limit is exceeded, the message is moved to the exception queue (also known as the dead queue or poison queue), and manual intervention by a system administrator will be necessary to resolve the problem and progress the case that the message belongs to.
When the data associated with a message is internal to the TIBCO iProcess Modeler, transactions generally succeed. However, if a transaction involves one or more EAI steps, it is possible for the transaction to fail repeatedly - either because the external system that the EAI step needs to communicate with is unavailable, or because the interface between the TIBCO iProcess Modeler and the external system has not been properly defined.
The SW_QRETRYCOUNT system field (introduced in Version 10.5) returns the number of times that a message in a message queue has failed. The field’s value is
0 the first time a message is processed, and is incremented each time the message fails. For example, if a
BG process is processing a message and
SW_QRETRYCOUNT = 2, this means that the
BG is attempting to process the message for the third time.
|
|
The SW_QRETRYCOUNT field only returns a meaningful value when it is used during the processing of a message by a BG process. If it used in any other circumstance (for example, displayed on a form) it will return SW_NA. If you want to display the value in a form or use it elsewhere in the procedure you must first use an EAI Script step to assign it to another field, as part of the same transaction.
|
Using SW_QRETRYCOUNT to Provide Exception Handling for EAI Steps
The procedure extract below shows a simple example of how you can use SW_QRETRYCOUNT to build suitable exception handling into a process. Following the release of the
Authorize step, an EAI step (
Call to external system) is used to perform an update to an external system. To allow for the possible failure of this step, a condition has been inserted immediately before it which checks the
SW_QRETRYCOUNT value for the message. Once this value reaches
2, the procedure diverts down an exception handling path.
When the Authorize step is released, a message is enqueued in which the condition and
Call to external system step are processed and, if the
Call to external system step succeeds, the step following it is sent out.
When a BG process first processes this message
SW_QRETRYCOUNT has a value of
0 so the
Call to external system EAI step is sent out. However, if the
Call to external system step fails the transaction is rolled back,
SW_QRETRYCOUNT is incremented to
1 and the message is retried.
If the message fails again - for example, because the external system being called is still not available -
SW_QRETRYCOUNT is incremented to
2 and the next retry will divert the process down the exception handling path. When this happens:
|
1.
|
The Store QRETRY values (EAI Script) step assigns the current SW_QRETRYCOUNT value (in this case, 2) to a numeric field that can be displayed in the Exception Step form. For example:
|
SW_QRETRYCOUNT:=EAI_FAIL_COUNT
This is necessary if you want to make the SW_QRETRYCOUNT value available on the
Exception Step form,
because SW_QRETRYCOUNT has no meaningful value outside the scope of the current message being processed by the BG process. If you simply mark
SW_QRETRYCOUNT on the
Exception Step form it will display as
SW_NA when the work item is opened.
|
2.
|
The Exception Step is sent to the system administrator. This completes the transaction and the message is deleted from the message queue. The Exception Step can, if required, use the EAI_FAIL_COUNT field to display the number of times that the EAI step has failed. It should also provide:
|
|
−
|
a Yes/No field or similar decision point to allow the administrator to specify whether or not the procedure should loop back to retry the Call to external system step again - depending on whether or not they are able to resolve the problem with the external system.
|
Assuming that the administrator has investigated and successfully resolved the problem with the external system, they then release the
Exception Step. A new message is enqueued and processed by a
BG process:
|
1.
|
The Retry the EAI loop condition is evaluated and sends the procedure back to retry the Call to external system step again.
|
|
2.
|
This time, SW_QRETRYCOUNT has a value of 0, because it is a different message. The Call to external system step is therefore sent out again and should now succeed, allowing the transaction to complete successfully and the case to proceed to the EAI call succeeded step.
|
A continuous sequence of EAI steps, or a number of EAI steps executed in parallel, are all processed as part of a single transaction (or message) and will therefore have a single
SW_QRETRYCOUNT value. Exception handling cannot therefore be implemented on a per-EAI step basis in this case.
In the example shown below, which uses a series of Call to external system EAI steps, the transaction will be rolled back if a single EAI step fails and
SW_QRETRYCOUNT incremented for the whole series.
Similarly, in the following example two parallel Call to external system EAI steps are executed as part of the same transaction. If either of the EAI steps fail the transaction will be rolled back and
SW_QRETRYCOUNT incremented. Neither of the
EAI Call Succeeded steps will therefore be sent out unless both EAI steps succeed.
If you want to use SW_QRETRYCOUNT to implement exception handling on a per-EAI step basis, so that failing EAI steps are independent of each other, you must split the EAI steps up so that they are processed as separate messages/transactions. You can do this by using multiple branches, preceding each EAI step either with a normal step (see
Using Multiple Branches with Normal Steps), or with a Transaction Control Step (see
Using Multiple Branches with Transaction Control Steps).
In the following example, two parallel Call to external system EAI steps are executed in separate branches. Each branch is started by a different message, when the
Start Branch 1 and
Start Branch 2 normal steps are released. This means that:
|
•
|
the Call to external system EAI steps succeed or fail independently of each other. One branch can progress to the wait step even if the other is failing. 
|
|
•
|
Commit and Concede, where the BG process commits the transaction and posts a RELEASE message back to the queue.
|
|
•
|
Commit and Continue, where the BG process commits the transaction but then immediately continues processing the rest of the message as a new transaction.
|
In the following example, two parallel Call to external system EAI steps are again executed in separate branches, but this time Transaction Control Steps are used to control the processing of each branch. Further, each branch uses a different type of Transaction Control Step to illustrate the difference in the way that each type is processed:
|
•
|
Commit and Concede (Deferred) operation: When the Branch 1 (Deferred) step is released, the BG process commits the current transaction and posts a RELEASE message back to the queue. Branch 1 is processed when the RELEASE message is dequeued and processed, and therefore has its own SW_QRETRYCOUNT value associated with the RELEASE message.
|
|
•
|
Commit and Continue operation: When the Branch 2 (Continue) step is released, the BG process commits the current transaction, but then carries on and attempts to process Branch 2 - effectively as part of a new transaction. If the Call to External System2 EAI step fails, the BG process rolls back to the Branch 2 (Continue) step, but cannot increment the SW_QRETRYCOUNT value because the message associated with that step no longer exists - having been removed from the message queue when the transaction was committed.
|
However, the retry delay defined for the Transaction Control Step effectively sets a deadline on the step. When this deadline expires, a process case (PROCCASE) message is posted to the message queue. When this message is processed, Branch 2 is retried. If the
Call to External System2 EAI step fails again, the PROCCASE message still exists, so the
BG process can increment the
SW_QRETRYCOUNT value and processing of the branch can continue.
|
|
In this case, Branch 2 has effectively failed once already before the PROCCASE message is processed.
|
Sub-procedures are processed entirely as part of their parent case transaction. For example, suppose that a
SUBPROC1 sub-procedure is defined to execute a single
Call to External System EAI step, as follows.
Now assume that SUBPROC1 is called from a procedure as shown below:
When the Branch 1 (Deferred) step is released, the
Call SUBPROC1 sub-procedure and
Call to External System EAI step are both processed as part of the RELEASE message. If either the sub-procedure or the EAI step
fails, the transaction is rolled back,
SW_QRETRYCOUNT is incremented and the loop retried in the normal way.
|
|
If you are upgrading from or importing procedures from pre-10.5 versions of the TIBCO iProcess Modeler, you should note that the transaction boundary has changed in this case. This is because sub-procedures are now processed entirely as part of their parent case transaction, whereas in earlier versions the transaction would be committed when the sub-procedure completed successfully.
On a pre-10.5 version of the TIBCO iProcess Modeler, if Call SUBPROC1 succeeded, the transaction would be committed and a sub-procedure done (SUBDONE) message would be posted to the queue. The following Call to External System EAI step would then be processed when the SUBDONE message was dequeued. It would therefore have its own SW_QRETRYCOUNT value associated with that message.
|
