Skip to Content
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. imagecheckError is the small user defined function used here. The code is as follows. image 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:-image Following screenshot shows descriptions of steps used in the BPM.  1) Receive Step – of File Input Message Type, Abstract, Asynchronous Message Interfaceimage2) Block Step- Used to raise/define an Exception with Exception Branch. In this fig, I have given Exception Name as “runTime” image 3) Transformation Step- To execute the Mapping. Whenever mapping exception occurs, it throws an exception to Exception Branch. image 4) Exception Branch- It used to handle the defined exception.image 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.image 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. image 7) Send Step – to send the output to Receiver- Output File Message type- Abstract, Asynchronous Message Interface. imageFor 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.
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Artem Osukhovsky
    I have some questions.
    1. How does BPM gets stopped – by triggering an alert or by means of the same mapping with unhandled exception in next transformation step?
    2. What if source message (not mapping) contains erroneous data? How can user correct it? Data must be changed in container element of last work item or anywhere else?
    I think that there is a need of more complicated weblogs with different reconcilation variants involving end-user interaction (not the developer or admin).
    1. Krishna Moorthy P Post author
      1)Like there is always dependency..
      2)Idea behind this is whenever any error has come, it should be notified to the customer/end user. But they don’t want to reprocess the processed data.. So they want to reprocess from the point where it has got error…The blog shows just a very simple scenario. There will be any type of error during that transformation step. For e.g Communication failuer/System failure/JCO connection failure. This time you need to reprocess from that point..But this was the requirement from one of customer.
      You are right here, for end user interaction is concerned.


      1. Artem Osukhovsky
        Thanks for fast answer! Sorry but it is still unclear for me – why process will stop after control step triggering alert? it is because of alert or because of next “bad” transformation(in common send/receive/…) step?
        Little offtopic: can you tell me – what would happen if we stop xi box during BPM execution(for example in step waiting for answer message)? Can it be restarted from interrupted processing step? Is there possibility to automaticaly restart such interrupted processes?
        Best regards!
        1. Artem Osukhovsky
          For first question i’m already find out right answer by looking at workflow log from your next weblog 🙂
          it’s only offtopic left.. 🙂
  2. Derek Colley
    Nice blog, thanks.
    Can you tell us what would happen if the restart attempt fails? Would the error be caught by the “exception block”?
  3. Praveen Sirupa
    In case of asynch(file)-to-asynch(file) scenarios like the one used in the blog which actually doesn’t require BPM, we can configure alert rules to be sent for mapping failures and other failures, can’t we? What do you say?

    I think your approach will be helpful in cases where BPM is unavoidable since configuring alert rules for failure of BPM mapping steps is not possible form RWB.


Leave a Reply