A common problem with any Integration solution is in providing proper error information to the call initiater when hit with failures. These failures could be due any of the reasons like back end system avialability, network errors, auhorization failures, data inconsistency , database specific errors, mapping failures etc. With XML Webservices forming the backbone of any SOA based landscape, propagating meangful error information to the calling client is essential. This weblog will present the importance of defining Fault Messages and different ways of handlying exceptions. This weblog is aimed in armoring a XI developer with execpton handling design patern that he/she could propose to the application developer. Sample code in Java , C# , VB will also be provided for handling exceptions.
To better understand the problem at hand, let us assume there is an Enterprise Webservice reqestCustomerDetails which gets custmer information based on various request paramters. You have finished development in Integration Repository and have configured the scenario in Configuration Directory. The wsdl for the scenaro is generated and communicated back to the application developer. Let us assume the consuming application is a .net application in our example. The developer generates proxies from the wsdl, codes the logic of calling the webservice in the application for getting customer informaion.
During application testing the call to webservice fails. This could be due any number of reasons, most common errors are listed bellow.
1. Wrong Communication Channel/Party/Service
2. Missing Reciever Determination
3. Missing Sender Agreement
4. Missing back end Authorizations for the service userid.
But for all the above errors the calling application gets an Exception
with no inidcation as to what the actual error was. Some of these can be easily traced by the XI developer in SXMB_MONI or RWB. But CPACache and back end authorizations errors would take a substantial digging for resoultion. In most of the cases XI developer gets a call saying a particular interface failed, what would be more useful for getting the turn around time of issue fixing would be some error specific information like <b>”No authorizaton for RFC group XXX”</b>.