Should a new custom ESB contract wsdl required for such a scenario?

Question

Hi,
I am using AIA 2.4 for my client who is integration Web-center 11g with JDE 9.0. The question is more pertaining to design approach that one needs to take for a scenario as this-
The case - an ADF page tries to create a customer in the JDE and uses AIA layer for the movement of business data.Once the customer gets created in the JDE,JDE in turn returns the client Id which ADF needs to navigate to a different page.The ESB currently is based on the entity WSDL(CustomerPartyV2.wsdl) and the operation is create. Since create ops in the above Entity contract is defined as 'async-one way' we cant get any response back to the ADF page via the provider ABC service.
Now to break the impasse, client has suggested if I can extend the entity wsdl file and create a new process wsdl file.But I couldn't convince myself as the need for a custom wsdl file for the EBS. This is becoz we are neither adding new operation nor we are extending a new EBO. The only thing that needs to be done is to make the create operation from async to sync in the wsdl. Unfortunately the Integration guide for 2.4 doesn't lay-down any step as how to tackle such an issue.
Please provide me some guideline on design as how to approach this problem and break the impasse!
Thanks
Prabal
Edited by: user10797754 on Apr 1, 2010 9:14 AM
Edited by: user10797754 on Apr 1, 2010 1:36 PM
Edited by: user10797754 on Apr 1, 2010 1:40 PM

Answer 1

Hi,
In AIA, the CRUD operations but for Query have implemented Asynchronous request / response patterns. Hence, these interfaces are modeled 2 one-way operations. The programming model stated in Integration Development Guide does specify how the client (in AIA, it might be Requester ABCS) can optionally choose to receive the outcome; and also about how the provider service needs to be coded to handle this.
The “responseCode” attribute of the EBM verb is set to indicate to the providing service that the requesting service is expecting a response. This is evaluated in the providing service to send back a response. The Create verb has an optional “ResponseCode” attribute that communicates the payload that is expected in the response message to the “Create” request. . The possible values for the ResponseCode are restricted to either “ID” (response payload is expected to be the Identifier of the object that was created) or “OBJECT” (response payload is expected to be the entire object that was created).
Even though the above programming model does allow for client services to receive the responses about the outcome of create / update / delete / sync operation in an asynchronous way, I would strongly discourage ADF page making a synchronous service call which in turn leverages AIA's asynchronous request / response pattern based services. This synchronous - asynchronous pattern could have performance impact.
I would make two recommendations - one is to follow customer's suggestion - add a new synchronous request / response based operation in process wsdl. But that means, you need to implement requester as well as provider services for that operation; and have ADF page invoke that synchronous requester ABCS.
The other option is to leverage the delivered existing services - clone the requester ABCS and make changes to cloned requester ABCS to update the requester application after receiving the response. Instead of cloning, you could also decide to make inline changes to the delivered requester ABCS - but need to be aware that those changes are not upgrade safe.
The user experience will certainly have to be modified - have the user refresh the screen - refreshing the screen should result in retrieval of the identifier from the data store ; and that could be used to navigate to the specific object. There might slightly be an inconvenience to the end user - but the implementation has all of Quality of Service characteristics such as resiliency, transactionality, guaranteed delivery etc.
Hope it helps.
regards,
Ravi
I