How to use the UserExit/extensions feature in AIA

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.

2. 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/

In our scenario Go to the

http://<host_name>:<port>/AIAComponents/ExtensionServiceLibrary/Agile/ProcessEngineeringChangeOrderAgileReqABCSExtConcrete.wsdl

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 the PreProcessABM 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

          <soap:address location="http://<hostname>:<port>/MirrorServlet/mirror"/>

Modify the soap:address location value to the ESB soap Endpoint URI

<service name="ProcessEngineeringChangeOrderAgileReqABCSExtensionService"> 

  <port name="ProcessEngineeringChangeOrderAgileReqABCSExtensionService_Port" binding="tns:ProcessEngineeringChangeOrderAgileReqABCSExtensionService_Binding">

   <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" location="http://<hostname>:<port>/event/AIASystem/Extension/ProcessECOExtensionESB" />

  </port>

 </service>

7. Final step is to enable this User Exit point

· Open <AIAHOME>\config\AIAConfigurationProperties.xml

Go to ServiceConfiguration tag and activate the User Exits by changing the attribute values to true. Here we have enabled the UserExit1 (PreProcessABM)

<ServiceConfiguration serviceName="{http://xmlns.oracle.com/ABCSImpl/Agile/Core/ProcessEngineeringChangeOrderAgileReqABCS/V1}ProcessEngineeringChangeOrderAgileReqABCS">

<Property name="ABCSExtension.PreProcessABM">true</Property>

<Property name="ABCSExtension.PreProcessEBM">false</Property>

<Property name="ABCSExtension.PostProcessEBM">false</Property>

<Property name="ABCSExtension.PostProcessABM">false</Property>

<Property name="TRACE.LOG.ENABLED">false</Property>

……………………..

……………………..

</ServiceConfiguration>

Save the config file.

· Login to http://<host_name>:<port>/AIA

Navigate to Setup tab > Configuration

Press Reload button to reload the entire AIA related configuration XMLs.

We are all set to test the custom user extensions. Run a test case scenario and see the custom ESB and BPEL process extension getting invoked.

Special thanks :: Nikhil, Sandhya and Rajesh for their inputs and help.

Co-existence of AgileEbiz and MDM PIPs

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-Ebiz PIP, 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 was eis/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.

transaction in 10.1.3.3 to handleTopLevelFault in 10.1.3.5 for global transaction

In one of my projects we were upgrading from 10.1.3.3 to 10.1.3.4. There were many processes which were configured to take part in global transaction. After upgrade to 10.1.3.4 the expected behavior during error scenarios seemed to be inconsistent. The rollback in different error scenarios were not happening properly since the error was getting swallowed at different touch points. That’s when it was realized that there is a new process parameter/flag named ‘handleTopLevelFault’ which has been set to true by default. Setting this to true means the fault will be handled at the scope specific exception block and rest of the process will be unaware of any error. So workaround was to set the parameter handleTopLevelFault’ to false.

In 10.1.3.5, property named transaction in configuration section of bpel.xml is renamed to handleTopLevelFault.

Snippets from release notes:

In case of unhandled exception, BPEL will not re-throw the exception. Configuration property handleTopLevelFault set to false will cause re-throw of exception.

Property named transaction in configuration section of bpel.xml is renamed to handleTopLevelFault in 10.1.3.5. If handleTopLevelFault is set to true, BPEL will not bubble up the unhandled exception. If it is not set, BPEL will bubble up the exception.

Reference : 7594608 Oracle SOA Platform 10.1.3.5

how to address security concerns : OWSM –do we really need it??

Security is a major factor to consider when you are designing a system. It depends on a lot of factors like the systems involved in integration, the type of information, the mode used for exchange of data etc. There will be lot of handshakes within the organization and with outside entities. Every client will have their own security measures and standards in place which has to be met before they will allow the integrations to be in production. So getting security clearances is a major roadblock (necessary evil) in all projects. So always make sure addressing security concerns becomes part of your design process.

Security is a vast topic and to define security we will need to know what all concepts it deals with. I have listed the core points that constitute security.

• Authentication: an act of establishing or confirming something as authentic, that is, that claims made by or about the subject are true

• Authorization: is the function of specifying access rights to resources

• Integrity: has to do with perceived consistency of actions, values, methods, measures, principles, expectations and outcome.

• Confidentiality: is ensuring that information is accessible only to those authorized to have access" and is one of the cornerstones of information security.

• Non-Repudiation: is the concept of ensuring that a party in a dispute cannot refute the validity of a statement or contract.

In today’s world where the users /systems are spread across the globe and communications happen over internet there are high chances that any of the above factors may be compromised. We will see the different methods that are being currently used for securing the data transfer between systems.

I will mention the most widely used methods

· Transport Level Security -- TLS/SSL/VPN/ HTTPS (The most widely used)

· Message Level Security --WS-Security (Open Standard)

Transport Level Security

The SSL/TLS VPN gateway often authenticates the client. If the client does not have a digital certificate, the VPN gateway may send the client a request for other authenticating information—usually a username and password. When the client responds, the SSL/TLS VPN gateway checks if the authenticating information is correct. A virtual private network (VPN) provides a secure communications mechanism for data and other information transmitted between two endpoints.

- Transport-level security (e.g. HTTPS) is a point-to-point security model where the channel is protected between two parties. However, many times the service consumer and service provider are separated by intermediaries (e.g. an Enterprise Service Bus).

- SSL/TLS VPN gateway authentication often is vendor-specific. So are most other aspects of SSL/TLS gateway operation.

Message Level Security

In situations where the service consumer and service provider are separated by intermediaries, message-level security can provide an end-to-end security solution. The secret is that with message-level security, you can encrypt the message using the public key of the final destination. In this way, only the intended receiver can decrypt the message.

Web Services Security (WS-Security) is an OASIS standard to describe how to implement message-level security with Web services. Specifically, WS-Security describes how you can add confidentiality (e.g. encryption), integrity (e.g. digital signatures), and authentication (e.g. username and password) to a SOAP message. In most cases, XML encryption and XML signatures are the mechanisms for securing the message.

- Message level security secures the message content itself, but it does not secure the communication channel.

- To apply message security, you have to make several configurations on both the client side and the server side.

So when you build integrations you will need to accommodate either message level or transport level security to the messages send across to different systems.

This is where OWSM comes to our help. It is one place where we can configure the security features that you want to incorporate whether its message level or transport level. This tool acts a gateway to incoming and outgoing messages .We can setup policies where message can be decrypted in request pipeline and encrypted in response pipeline.

I am listing down interesting factors which will make it an attractive option for solving your security issues.

• OWSM is a proxy that runs in the App Server

• Accepts or rejects incoming requests like a firewall

• Transport protocol translation

- Incoming: HTTP(S), JMS, MQ

- Outgoing: HTTP(S), JMS, MQ, or a custom protocol

• Supports both SOAP and standard XML messages

• Content Routing

• Policy - Set of operational tasks that are performed at a Policy Enforcement Point

• A Policy is separated into

– Request Pipeline – A set of policy steps that are executed during the processing of a Web Service request.

– Response Pipeline – A set of policy steps that are executed during the processing of a response to a Web service request

This makes the integration process independent of any security related programming. OWSM will act as a centralized server for managing all your security concerns. Thumbs up from me J