AIA FP and PIP installations are always tricky and can throw up different issues in different environments. For one of the clients we had successfully completed the AIA PIP installation but there were couple of build scripts which had failed due to certain environment issues.
All the BPEL/ESB processes that are part of AIA will be plugged in with a feature to enable CAVS testing. This helps in doing individual testing of the processes developed to form part of a PIP. So all the processes will have routing to the CAVS, which will be a generic WSDL. The EBS services that come with PIPs (ESB processes) will be shared among different business process flows. So depending on the PIP that you deploy the Routing rules gets added at a PIP specific installation.
For all these routing rules to be added it becomes mandatory to have all the endpoint up and running, and since CAVS URL is one among them, it also needs to be available at time of installation.
CAVS ESB is referring to the wsdls inside the AIAApplication.ear, but the AIA app urls were not accessible even though AIAApplication was up and running.
) was AIAValidationSystemServlet and the search for this context directed us to AIAApplication.ear .
As a workaround we redeployed the AIAApplication.ear and all the wsdls became accessible. But once the server gets restarted the AIA app urls become inaccessible.
AIAApplication was not starting up even though the application was deployed.
The workaround didn’t work for long. So finally we had to zero in on the issue to solve it.
This issue is with having registry.ear and AIAApplication.ear together .There seems to be a conflict in starting these applications together due to shared resources of different versions being used by both applications. So as a workaround we modified the order in which the applications are loaded at server startup.The entries were modified in server.xml and default-web-site.xml with AIAApplication entries above the registry entries.
Siebel CRM Integration Pack for Oracle Order Management: Order to Cash 2
In the recent past the hype on AIA has reached a new high than compared to the past few years when the idea was conceived and implemented. The AIA PIP’s have matured a lot coming from 2.1 to 2.5.
In today’s write-up, I will be focus more on the Transformations involved in the PIP flows. Since PIPs needs to be configured for each customer requirement, there will be some customizations involved like custom mapping to be done from ABM to EBM to ABM. To cater to this need AIA provides the Custom XSL feature which will be part of all the processes. This is achieved by embedding Call Custom Template tags under each category.
The PIPs developed till date may not have completely complied with all the standard practices. I will familiarize you with the practices Oracle have followed in couple of PIPs namely Design to Release, Order to Cash and MDM Product PIPs.
I will first go with my favorite one.
D2R PIP
On Agile Requestor side, the artifacts particularly the transformations (both main and Custom XSL) are accessed from the server repository.
In case of Ebiz Provider process, only the custom transformations are accessed from the server repository. The main XSL will be embedded with the process. The selection between main XSL and custom XSL is decided based on a property defined in AIA Configurations file.(code snippets below will give you a better idea)
The main difference between both sides is that on Agile side mappings on both XSL files will be used for mapping where as in the case of Ebiz there is always a option to decide whether to use either main XSL or custom XSL. Both XSL’s can also be used (similar to Agile) in conjunction as call template feature to custom templates are embedded in the Main XSL.
If the CUSTOM.TRANSFORMATIONS.EBM_TO_ABM parameter in AIA properties file is set to true it will completely skip the main XSL file and use the Custom mapping file. You will need to do all the mapping in the custom XSL as the main XSL is skipped.
O2C flow & MDM Product Flow
This looks like one of the earliest PIP’s developed as no standards for the transformations has been followed. All the XSL’s (main XSL and Custom XSL) are tightly couple to the process .So any customizations on these XSL’s have to be done inside the BPEL_HOME/domains/default/tmp folder.
Best Practices
In AIA all the artifacts including ABO, EBO, ABM, EBM XSD’s and EBS WSDL’s are supposed to be placed in a common server location (ORACLE_HOME\ Apache\Apache\htdocs\AIAComponents) and accessed via the server host URL –http://serverhostname:port/AIAComponents.
All the transformation files (mapping XSL files) should be uploaded in the Apache location and participating processes must be independent of any XSL files. The most common customizations that will be done on pre-integration packs will be adding new custom fields and new mappings. If all these objects are referred from a location outside the process the impact to the processes due to changes can be kept to minimum.
A property in AIA configurations file should be used to decide whether to use either main XSL or custom XSL. It will help us in isolating all the mappings to a single file instead of looking around in both the XSL to figure out an issue.
That’s it for today. Special thanks to Sandhya, Nikhil, Anil and Rajesh for their inputs.
To create a Pre-integration Pack to suit all the requirements is impossible, but to work around that by providing plug-in points so as to add custom functionalities to meet different requirements is an example of well thought and implemented architecture. AIA PIPs comes with this feature of user exits built in to the integration process flow which makes it easier to add custom processes at different points to cater to the different requirements of the client without touching the core business flow of the PIP. This blog explains on how to use user exit feature in case you have a requirement to create a custom functionality not supported out of the box by PIP.
Whenever you need to add some additional functionality into the PIP, first point you need to consider would be to use the extension feature available with the PIP. This feature is also called as User Exit. By default for normal business flows, PIPs comes with 8 extensibility points basically 4 on the Requester ABCS side and 4 on Provider ABCS side. User Exits points on requester side will be present prior to:
·execution of transformation of ABM to EBM.( PreProcessABM)
·invocation of Enterprise Business Service.( PreProcessEBM)
·Execution of transformation of EBM to ABM. (PostProcessABM)
·invocation of callback service or response return.( PostProcessEBM)
And on Provider side prior to
·execution of transformation of EBM to ABM. ( PreProcessABM)
·invocation of Application Service. .( PreProcessEBM)
·execution of transformation of ABM to EBM. (PostProcessABM)
·invocation of callback EBS or return of response message.( PostProcessEBM)
By default all these user exits will be disabled and can be enabled by modifying entries in the AIA config file.
I will take you through different steps involved in activating and using User Exits. Here I will explain based on ECO sync scenario on the Agile-EBIZ PIP.
Steps
1.To start of with inspect the ABCS process (Requestor /Provider) .Check for an Extension Service .In this case it will be ProcessEngineeringChangeOrderAgileReqABCSExtensionService. If you see the Partner link will be referring to a Abstract wsdl which will be referring to a concrete wsdl on the Server. Or else you can check out the wsdlRuntimeLocation property in bpel.xml for the service related partner link binding. Runtime location will refer to a wsdl in AIAComponents/ ExtensionServiceLibrary.
All the concrete wsdls related to the extension library will be defined under the AIAComponents/ExtensionServiceLibrary and in runtime will refer form the location -- http://<host_name>:<port>/AIAComponents/ExtensionServiceLibrary/
3.As a best practice all the extensions will be routed via an ESB process. So next step will be create ESB routing service based on the concrete wsdl.
·create a local copy of the concrete wsdl (mentioned in step2)
·Remove the Soap service tags from the wsdl.
·Create an ESB process
·Assign proper System/service groups
·Create a Routing service using the local copy of the wsdl. Routing service will have 4 operations each for each user exit.
4. Next create a BPEL process which will contain the custom functionality required by the client.
·Create an empty BPEL process
·Create a local copy-2 of the concrete wsdl
·Since the BPEL process will be specific to a UserExit the operations/entries related to other User exits can be removed. In the case of UserExit1 we will be using only thePreProcessABM operations, so remove unwanted entries related to PreProcessEBM, PostProcessABM and PostProcessEBM .It would be a trimmed version of the wsdl.
·Create a Partner Link in the BPEL process with the local copy-2
·Add a receive and reply activity and link it to the partner link. The input and output variables will be of the same message type.
·Add the custom functionality in between receive and reply activity.
·Once the custom functionality is added deploy the process.
5.Next step will be to link the ESB process with the custom BPEL process.
·Open the ESB process
·Add a soap service with the WSDL URL of the BPEL process.
·Select soap service(aka BPEL process)as the target for routing rule corresponding to PreProcessABM operation
·Save it and register the service.
6.Next step is to link the concrete WSDL on server to the ESB routing service
·Go to the extension library folder –physical location will be
<Oracle_HOME>/Apache/Apace/htdocs/AIAComponents/ExtensionServiceLibrary .Open the concrete wsdl related to the flow. Go to the services tag.The default location will be
Go to ServiceConfiguration tag and activate the User Exits by changing the attribute values to true. Here we have enabled the UserExit1 (PreProcessABM)
I would like to put down some findings from R&D on co-existence of Agile-Ebiz and MDM PIP. The environment that we were looking at had an Agile system, an Ebiz R12 with Item and Variant Management modules and Ebiz R11i .
For Agile-EbizPIP, Agile will be the source system and Ebiz R12 instance will be the target and for MDM PIP Ebiz R12 will act as the MDM or PIM (source system) and Ebiz R11i the target system.
Task was to see whether the Agile-Ebiz and MDM PIP will co-exist on the same AIA environment. On top of a fresh SOA 10.1.3.4 environment we installed the AIA FP 2.5 and Agile-Ebiz PIP .One round of testing was successful. On this we tried the MDM PIP with Oracle Ebiz R12 and Oracle Ebiz R11i as source and target systems. After that we ran one more round of testing on Agile-Ebiz PIP and some functionality failed. Generate Item number service had failed. So we started analyzing the errors and processes affected due to the co-existence of MDM PIP to zero-in on the affected processes.
In case of Agile for Item sync scenario there is a SyncItemListAgileReqABCSImpl process calling Item EBS and that calls SyncItemListEbizProvABCSImpl which in turn invokes the SyncItemListEbizAdapter and this process will interact with the Ebiz systems. The response is send back by SyncItemListEbizProvABCSImpl through ItemResponseEbiz EBS process where routing will be to SyncItemListAgileReqABCSImpl process.
In case of MDM for Item sync scenario there is a SyncItemListPIMReqABCSImpl process calling SyncItemListEbizProvABCSImpl which in turn invokes the SyncItemListEbizAdapter and this process will interact with the Ebiz systems. The response is send back by SyncItemListEbizProvABCSImpl through ItemResponseEbiz EBS process where routing will be to SyncItemListPIMReqABCSImpl process.
The flows are so similar, but the Requester process differs, so the response will also be routed to the PIP process which was installed later. In our case the since MDM PIP was installed over the Agile-Ebiz PIP, these routing rules are overwritten favoring the PIM systems.
SyncItemListEbizAdapter which interacts with the Ebiz system also was affected since the JNDI name used for Agile-Ebiz PIP was eis/Apps/EbizRA whereas for MDM PIP for Ebiz waseis/Apps/OracleAppsDatasource. Depending on the value it will hit different systems, in our case R12 or R11i.
To conclude it didn’t seem like a recommendable solution to have these 2 PIPs on the same environment. It could be made to work with lot of workarounds but would not make sense as the upgrades to the FP & PIPs will not be clean/easy as you will have to manually upgrade these workarounds.
