Reconciliation is a process of re-submission of messages after corrections that were failed in the previous run. This failure is may be because of Application errors, Run time Exceptions etc. Business Requirement is to trigger an alert for Application errors and continue the process from that point, after correcting the application errors (e.g. Mapping Runtime Exceptions). So to trigger an alert for application errors with dynamic text, BPM is used here. If the control step triggers an alert at runtime, Alert Management sends the alert to the relevant user. The process is not terminated and resumes on completion of the control step. The user is informed by Alert Management and then user needs to decide to discard the process or change the application which caused applications errors. But after correcting the application error , if the message should process from that point( where Alert has been triggered), without alter the rest of the process, then some workaround needs to be done in the BPM , so that after restarting the workflow instance, the process run smoothly. Note: This blog explains, necessary steps required in the BPM to reconcile the message from Mapping Runtime Exception. Here I have taken simple File->XI->File Scenario with Runtime Mapping Exception. Interface Flow:File is picked by Sender File Adapter and sent into BPM and in BPM transformation step is executed , if any runtime exceptions comes, alert is triggered from the BPM and if not it is sent to file successfully by Receiver File Adapter. After triggering an alert, if user wants to reconcile the message, then BPM needs to be configured accordingly so that user gets required, transformed data in the output. Reconciliation Logic: After getting the alert, user needs to go and fix the errors. If user restarts the Workflow after fixing the error, user will not get transformed data as required. Once user/developer restarts the workflow instance, message should be mapped as required. For this reason, Transformation step is executed once again in the BPM and this step will follow once workflow is restarted. Rest of the logic will remain same. Thus user can reconcile the message without reprocessing whole file/complete scenario. In this scenario, user needs to fix the Mapping, activate the Mapping. So that new, changed mapping should reflect in the BPM. It is so often that, you may need to refresh the cache, check for the Integration Process status in SXI_CACHE. Step 1: Integration Repository- Design Assumptions- Data Types, Message Types, Message Interfaces are in place. Create a simple 1:1 message mapping with small user defined function. This function is used here to demo this runtime exception in the Mapping. 
checkError is the small user defined function used here. The code is as follows. 
Create an Interface mapping between two abstract interfaces so that this can be used in the Transformation step of BPM. Create Integration Process with following steps. 1) Receive Step- To receive the File Input Message ( Abstract Message Interface of type File Input Message) 2) Transformation Step – to execute the Mapping 3) Block Step to trigger an Exception when any mapping runtime occurs 4) Control Step- To trigger an alert based on the Application Error/Runtime Exception 5) Transformation Step – ( After Triggering Alert- to reconcile the message- Please look into Reconciliation Logic section ) 6) Send Step- to send the transformed data Two container Variables: • To Receive the Message- File Input Message Type- Abstract • To Send the Message- File Output Message Type-Abstract Integration process design looks like this:-
Following screenshot shows descriptions of steps used in the BPM. 1) Receive Step – of File Input Message Type, Abstract, Asynchronous Message Interface
2) Block Step- Used to raise/define an Exception with Exception Branch. In this fig, I have given Exception Name as “runTime" 
3) Transformation Step- To execute the Mapping. Whenever mapping exception occurs, it throws an exception to Exception Branch. 
4) Exception Branch- It used to handle the defined exception.
5) Control Step – Within the Exception Branch – Control Step used to here to trigger an alert whenever Exception occurs. Observe the properties of Control Step. The mentioned Alert Category is defined in the Integration Server using transaction code ALRTCATDEF.
Once Alert has been triggered, it resumes the process. To reconcile the message or to restart the process after fixing the errors, workflow should be restarted from that point. 6) Transformation Step – This is used here to execute the Transformation once again, after restarting the workflow. Once workflow restarts, Transformation step will be executed so that you will get the expected output as the normal flow. 
7) Send Step – to send the output to Receiver- Output File Message type- Abstract, Asynchronous Message Interface. 
For Alert Configuration- Quick Steps1) Create an Alert Category in XI with the Tcode- ALRTCATDEF 2) As user required, throwing alert from the BPM with dynamic text, check the option of dynamic text. Even static text will also do. 3) As this alert is triggered from BPM, no need of any Alert Rules created in the RWB. 4) Use the Alert Category name created, in the properties of the Control Step in the BPM. And also provide Dynamic text in the Properties. Now Repository objects are done and activated. Step 2: Integration Directory: Configuration Create the configuration scenario, assign the Business system, created the communication channels of type File for Sender and Receiver, and create Sender Agreement. Create two Receiver Determinations- 1) File Sender ->BPM ( No Mapping) 2) BPM->File Receiver ( No Mapping) Create the Receiver Agreement. Save and activate all. Now Design and Development is done. To test the Scenario and Restart the Workflow please refer next blog.
checkError is the small user defined function used here. The code is as follows. Create an Interface mapping between two abstract interfaces so that this can be used in the Transformation step of BPM. Create Integration Process with following steps. 1) Receive Step- To receive the File Input Message ( Abstract Message Interface of type File Input Message) 2) Transformation Step – to execute the Mapping 3) Block Step to trigger an Exception when any mapping runtime occurs 4) Control Step- To trigger an alert based on the Application Error/Runtime Exception 5) Transformation Step – ( After Triggering Alert- to reconcile the message- Please look into Reconciliation Logic section ) 6) Send Step- to send the transformed data Two container Variables: • To Receive the Message- File Input Message Type- Abstract • To Send the Message- File Output Message Type-Abstract Integration process design looks like this:- Following screenshot shows descriptions of steps used in the BPM. 1) Receive Step – of File Input Message Type, Abstract, Asynchronous Message Interface2) Block Step- Used to raise/define an Exception with Exception Branch. In this fig, I have given Exception Name as “runTime" 3) Transformation Step- To execute the Mapping. Whenever mapping exception occurs, it throws an exception to Exception Branch. 4) Exception Branch- It used to handle the defined exception. 5) Control Step – Within the Exception Branch – Control Step used to here to trigger an alert whenever Exception occurs. Observe the properties of Control Step. The mentioned Alert Category is defined in the Integration Server using transaction code ALRTCATDEF. Once Alert has been triggered, it resumes the process. To reconcile the message or to restart the process after fixing the errors, workflow should be restarted from that point. 6) Transformation Step – This is used here to execute the Transformation once again, after restarting the workflow. Once workflow restarts, Transformation step will be executed so that you will get the expected output as the normal flow. 7) Send Step – to send the output to Receiver- Output File Message type- Abstract, Asynchronous Message Interface. For Alert Configuration- Quick Steps1) Create an Alert Category in XI with the Tcode- ALRTCATDEF 2) As user required, throwing alert from the BPM with dynamic text, check the option of dynamic text. Even static text will also do. 3) As this alert is triggered from BPM, no need of any Alert Rules created in the RWB. 4) Use the Alert Category name created, in the properties of the Control Step in the BPM. And also provide Dynamic text in the Properties. Now Repository objects are done and activated. Step 2: Integration Directory: Configuration Create the configuration scenario, assign the Business system, created the communication channels of type File for Sender and Receiver, and create Sender Agreement. Create two Receiver Determinations- 1) File Sender ->BPM ( No Mapping) 2) BPM->File Receiver ( No Mapping) Create the Receiver Agreement. Save and activate all. Now Design and Development is done. To test the Scenario and Restart the Workflow please refer next blog.
6 Comments
