Internal communication is a mechanism in SAP Cloud for Customer used for communication between business objects belonging to different deployment units. And with every communication, errors can occur. The SAP documentation describes the steps needed to define error handling using the SDK but it’s not so apparent what functionality you get once you go through all the steps. In this blog I will show exactly what functionality you get and how to use it.
My colleague Said has written an excellent blog “Cross deployment unit object creation” where he explains how to use Internal Communication to create a lead triggered by a change in a business partner. But what if instead of creating a new lead you want to change an existing object? This object might be locked by another user. Because of the asynchronous nature of Internal Communication, these errors might occur unnoticed unless you configure proper error handling.
The use case that I’m using here is to automatically change a ticket whenever an activity assigned to this ticket is changed. The business objects used in this example are:
In the BeforeSave-event of the HelperBO_Receiver I want to change the ticket. But whenever this is not possible (e.g. when the ticket is locked) the internal communication will proceed and the object will still be saved. Since processing is done asynchronously and this error does not show up on any monitoring screen, you will never know this error happened.
So how to stop processing in case of errors? In order to prevent the save, you need to implement the OnSave-validation. Next challenge, how to check whether the ticket is locked? The framework lacks functionality to check this (there is CheckLock-method in the PlatinumEngineering library but it’s not officially supported). A simple alternative is to read back any change you make to the ticket. The additional logic might look like this:
Now if something goes wrong the error is shown in view “Process Communication Errors” within the Administrator menu. Technically it’s view ITS_PROCESSCOMMERRORS in the SEODADMINWCF work center. Errors are shown under “Open errors with Incidents”:
So we are able to at least detect if something went wrong and see the cause but we are still unable to solve it. To enable a restart-mechanism you need to explicitly define error handling which consists of defining tasks for all recognized error situations. For a complete instruction see “Define Service Integration Error Handling“. In my case I extended the receiver business object with an exception TicketNotChanged and extended the OnSave-validation:
…and linked the exception to a task in the error handling section of the Internal Communication configuration:
With this configuration in place, the errors show up in a different section: “Open Errors with Tasks“. Notice the additional buttons in the right upper corner.
Now we can go a step further. Choose “Take Over Task”, refresh the list and choose “Edit”. It might happen that you get an error saying “You are not authorized to execute action on this Task”, in my case this error automatically disappeared the next day. Don’t ask me why, it just did. And finally a Restart-option appears:
If all goes well, the receiver business object is saved and the ticket is successfully changed.