This article introduces how the Oracle SOA-Suite can be used to conveniently integrate Oracle Fusion Applications with other business applications such as the Oracle E-Business Suite. It is the first article in a series that will cover all important aspects of the integration in depth.
The following topics will be explored to give a bird’s eye view of the integration setup:
- The example scenario used to demonstrate the scope of the integration
- The SOA-Suite
- The concept of event-driven interaction with SOA
- Implementation of loose coupling to provide the flexibility to use various target systems
One of the most common tasks in customer relationship management – the creation of a new customer account – will serve to demonstrate the integration. Figure 1 shows, how a person from the CRM creates a new account in the corresponding Fusion Apps form.
In order to utilize the customer data in other areas than CRM as for example in the order management or for invoicing, it has to be automatically distributed to other systems. In this article we will use the Oracle E-Business Suite as a target system. However, other systems such as SAP can be integrated in the same manner. Figure 2 shows the customer data that has been transferred to the E-Business Suite.
The Oracle SOA-Suite
So, what has been going on in the background? Just as for many other Oracle products, the SOA-suite provides the possibility to extend Fusion Apps with custom SOA processes. These are developed in Oracle JDeveloper and deployed to an application server, usually Oracle’s WebLogic.
Processes orchestrate services and are able to process or transform data that is passed from an invoked service. In the presented use case we are using a service that accesses the database of Fusion Apps and retrieves the newly created data. The process transforms the obtained data and puts it into EBS through another service. Of course you are not limited to EBS, other services that integrate different systems are conceivable. As mentioned above, integrating SAP instead of EBS for example would also be possible. Of course you are not limited to just one process that passes the transformed Fusion Apps data to another system. Multiple processes can receive data and put it into their target system. So it is possible to plug-in other systems that should be synchronized to the Fusion Apps data besides EBS.
JDeveloper enables the user to easily develop SOA processes. On an intuitive graphical user interface you can drag and drop process components and connect them the way you like. Figure 3 depicts an overview of such a process.
In Figure 4 you can see a drill down view that shows in which sequence the single steps of the process are handled and how the services are orchestrated.
But, how is the execution of such a process triggered? Here the Event Delivery Network comes into play.
The Event Delivery Network
A deployed SOA process that provides services as described above has to listen for and react on changes in the target systems. To realize this we are using an event-driven approach. That means that we define an event and assign it to a triggering process. Then we subscribe dependent processes to it. Once the event is triggered, the subscribed processes are initiated. In our use case such an event would be the creation of a new customer in Fusion Apps. To register and listen for events the Event Delivery Network (EDN) is being used. In the EDN, events are defined based on specific XML schemes. This article provides further details on the topic of event-driven SOA.
Since SOA-Suite provides the basis for Fusion Apps internal integration processes, some events are already built-in and triggered by default. So is the creation of a new customer. How to find and use these events will be discussed in a later article. Alongside the default events you can define your own individual events and register them on the EDN.
If you subscribe your SOA process to an event, it is invoked whenever the event occurs. On invocation it receives the event information to process it accordingly. In our use case the process gets the data from the newly created user as event information. In Figure 5 the event-driven execution of a process is shown. The initiating event is marked with a flash.
Above I showed a direct point-to-point option where the data is taken from one system and put into another. But what if more than one target system needs to be attached? You could pack more services in your SOA composite to integrate other systems. But this is inflexible and may get confusing very fast. The better option is to abstract. A separated SOA composite that reacts on the desired event is created. Referring to our use case this composite would be executed when a new customer is created in Fusion Apps. Quite similar to the process above it takes the customer data, but instead of putting it into EBS it triggers another custom event and fills it with the needed data. Now you can plug in target systems by creating a new composite for each system. These composites react on the triggered custom event by taking its data from and putting it into the attached system.
To implement this you need to consider the technical aspects of your integration processes. This includes both interaction patterns and business objects exchanged. A Business Process Modelling (BPM) tool like the Horus Business Modeler is perfectly suited for this demand. With it you can also model business objects alongside your technical processes.
Conforming these models you can create your own generic events to generalize and simplify the integration of new systems. Referring to our use case this works in the following manner:
I. A first composite subscribes the default Fusion Apps event indicating that a new customer has been created. It transforms the incoming customer data from the native Fusion Apps format into a generic event format which is derived from your business models. For our case that would be the “newCustomer” event format. Afterwards the composite triggers a „newCustomer“ event.
II. For every target system another composite is created which subscribes to the triggered „newCustomer“ event. It transforms the information of the event into the target format and puts it into the target system.
As described above the benefit of this approach is that you can repeat the second step for every new target system. So to integrate an additional system you simply have to create a new composite which transforms the desired generic event format in the target format.
After this overview of the topic we give you a perspective on the following articles that will cover the integration in more detail:
- Install & configure JDeveloper
- Deploy & debug processes with the Enterprise Manager
- Detect events of Oracle products
- Subscribe a composite to an event
- Create an individual event
- Trigger services