middleware | Phil (aka MP3Monster)'s Blog

Tags

AIA, Application Integration Architecture, FMW, fusion, middleware, Oracle, PIP, PIPs, Presentation, Process Integration Pack, slides, SOA, SOA Suite

I recently presented on the subject of Oracle middleware (FMW) with an emphasis on SOA Suite, Application Integration Architecture (AIA), Process Integration Packs (PIPs) and Oracle Fusion Applications. Below is a derivative of the presentation. I’ve sought to identify how the technologies relate, and how Fusion applications relate to the non Fusion products.

For those trying to get to grips with this technology stack – you might find the notes useful as I’ve included plenty of links to associated information.

Tags

ABCS, AIA, EBO, EBusiness, Foundation Pack, fusion, integration, master data management, MDM, middleware, OER, Oracle, PDH, PIP, product data hub, R12, Siebel, SOA

So as a road mapping question I have been thinking about the migration to using Fusion Apps so we have a road map and more importantly design patterns that will support a transitions from the likes of Ebiz R12, Siebel etc to their Fusion successors.

Example of Coexistance

In broad terms the application level transition through the principles of co-existence are well established. What is currently exercising the grey matter is the middle migration. Perhaps the best way to explain this is through an example. The Product Data Hub (PDH) solution exists to provide a Master Data Management capability for your widest and gadgets.

You will want to share that master data with other apps such as Ebiz so you can deal with say order management. All fairly obvious, and in Fusion Apps world the different components should inherently work together. Back in R12 world though you are probably going to be using the Product MDM PIP (Process Integration Pack) with the Ebiz extension pack. When using the PIP like this then it’s just a case of retiring the PIP. But this PIP is designed so that you can extend the process to publish Master Data to your own apps for example you also push the data to your design systems as you maybe sharing available parts data.

So now we have an extended PIP whic in a simple Fusion apps migration you’d leave behind. But leaving the PIP behind also means an integration gap. So what is the answer.

Well on the early days of Fusion Apps the suggestion was that AIA and PIPs would be part of the ongoing story. but the reality is little has moved in this space. Understandable, Fusion Apps development had been far bigger than anyone expected, if fusion Apps are directly conversant then how much real demand exists for the PIP transformation. So what is the answer, well at this stage I’m not sure. I can say I have seen ABCS’ mentioned in the public FusionAppsOER. We know that AIA Foundation Pack EBOs are realised in Fusion Apps albeit via ADF BCs.

Given Fusion Apps underpinnings are the same as AIA so it should be possible to drop the AIA Foundation Pack (FP) into your Fusion Apps environment (setting aside all the licensing questions it would raise). Can you therefore drop in the PIP and disable the legacy Oracle app elements leaving your custom extensions? Do you accept a rewrite of your integration all be it you should just need to redevelop the orchestration layer (ABCS’ for Fusion App exist and you can carry forward your own ABCS’ for your app such as the design system in our illustration)?