While configuring my Scenario, I came across the transactional behavior of the Business Process engine. It made it easier to track the error in any step of BPM. Also an inspirational comment by Mr. Bhavesh Kantilal, a popular contributor on SDN, to explain the transactional behavior of BPM made me take this opportunity to explain it with the help of this blog.
I have taken a very basic scenario to explain this behavior.
A file is placed on ftp. It is picked by the file adapter and delivered to the receive step of BPM. It passes through different mapping logics and sent back to the ftp.
BPM design.
Step 1) Receive step: - abstract asynchronous interface to receive the file.
Step 2) Transformation step: - First mapping.
Step 3) Block Step: - To accumulate various BPM steps.
Step 4) Transformation step: - Second mapping.
Step 5) Transformation step: - Third mapping.
Step 6) Send step: - abstract asynchronous interface to send the file
The mapping for the third transformation step is shown in the figure. I have deliberately failed the salary field in the mapping so as to explain the significance of the transactional behavior of BPM.
Block start and Block End have two values i.e. New transaction and No new transaction.
In this case they are set to New transaction.
When I place the file on ftp, process instance for the BPM is generated.
Go to SXI_MONITOR to monitor the process instance. As there is an error in the salary field for third mapping, BPM fails.
In order to track the cause of the error click on PE.
Select Goto and click on List with technical details.
Here we can see that the status of Block step is red, which implies that we can track the error up to the Block. This is because the Block start is set to new transaction. In case if it was set to no new transaction the error status would have been restricted up to BPM level.
In another case I have checked the Create New Transaction for the third transformation step.
Again I place the file on ftp, this triggers the BPM. As there is an error in the salary field, process instance fails. In this case when you check the technical details the error status for the third transformation step is also displayed. This is because the Create new transaction for the third mapping is checked.
Click on the container tab and Open the Trace field in it.
Here you can track the error up to the field level, as we can see that it displays the field (salary) for which the error had occurred.
We have seen the advantage of the transactional behavior; the disadvantage is that it decreases the performance. This is because for each step in which the transaction is activated database is updated
Hence we can conclude that the transactional behavior is an optimization between monitoring and performance. Based on the criticality of the step its transaction should be activated or deactivated.
References: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/200a4efc-f547-2a10-02bf-ada1d207...
5 Comments
