Tag Archives: PIP

AIA Rides Again?

23 Thursday Jun 2016

Posted by in General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , , , ,

canonicaldatamodel

For those who have been using the Application Integration Architecture on top of Oracle SOA Suite, will probably know that Oracle have sunset AIA as of 12c.  For 12.1 there are Core Extensions to help transition onto the 12c platform but 12.2 leaves these behind.

One of the more valuable parts of AIA for many has been the prebuilt but extensible canonical data model, which are then used by the Prebuilt Integration Packs (PIPs). Having a ready built canonical form can save an enormous amount of effort (consider the amount of effort invested by OASIS and other standards bodies to define standardised data definitions).

So with AIA not moving forward and the canonical form (i.e. XML Schema) no longer being maintained. The question begs how to move forward?  Well given that the model is represented by XML schema you could harvest the schema from an 11g environment, package them up and deploy them in a standalone manner in a 12c environment.  Whilst this will work, it does mean that the data model wont have any future evolution other than by home grown effort.

Depending on your commitment to the AIA model, there is another option to adopt another prebuild form.  I know as result of talking with several other Oracle AIA customers that people are adopting OAGIS.  This isn’t surprising as they have similar characteristics in the way to extend, the way the definitions are defined and structured etc.  Not to mention some common ancestry. However if you have a significant level of utilisation moving to a new model is potentially going to have a significant level of impact.

image008As we have also elected to go the OAGIS route (but fortunately are fairly youthful in our adoption so have elected to switch quickly for all but a couple of objects types. Given this,  I periodically check in with the OAGIS website to come across the following:

Oracle Enterprise Business Objects Contributed to OAGi 
We are very pleased to announce that Oracle has contributed their Enterprise Business Objects (EBOs) and associated IP to OAGi!
The Oracle EBOs are based on OAGIS BODs from a past release and no longer supported by Oracle so they contributed them to us to harmonize with the current version of OAGIS and preserve a technology path for EBO customers.
This also gives OAGi an opportunity to further improve OAGIS content and scope.
I take this as proof of Oracle’s commitment to Open Standards and plan to say so in a press release.  I personally thank Oracle for this commitment.
Scott Nieman of Land O’Lakes will be presenting his Project Definition to begin the process of harmonization on Friday, June 3, at 11 AM EDT at the Next meeting which, as members, you are all invited. Please let me know if you don’t have an invitation and I will forward it to you.
Please join me in thanking Oracle and also please try to engage in our harmonization process to improve OAGIS.

So the basis of this is that OAGIS will gain greater coverage of their domain views. But additionally Scott Nieman will be blazing the way to easing the migration path. I have been fortunate enough to meet and talk with Scott at Oracle Open World and it will be worth keeping an eye out for his findings.

Deployment considerations for Oracle Product Hub

09 Wednesday Sep 2015

Posted by in General, Oracle, Technology

≈ Leave a comment

Tags

, , , , ,

Aside from being big users of Oracle Middleware we use  make use of a range of Oracle application capabilities from the EBusiness Suite family. This includes several of the ‘hub’ products such as Product Data Hub which is central to our Master Data Management strategy for product data definition and creation. A commitment to remove all the different components in the legacy estate that can author or modify product data was made and has been rolled out – not all legacy authoring solutions have been decommissioned although this is more the nature of our legacy deployment strategy.

When we setup PDH the organisation went through a lot of internal debate on whether to deploy PDH as part of our core transactional  EBusiness Suite which performs all our accounting (and a lot more complex than may appear to be) or to adopt a separate deployment approach and keep the instances in sync using the Product Data MDM Process Integration Pack (PIP) which includes an extension to integrate with EBusiness. This later approach prevailed. However we are now in a place where we are having to re-examine this decision as a result of the PIP’s EBusiness extension hitting end of life (Oracle’s declared position being that the extension has so little adoption that it is economically not sensible to maintain it).

Rather than drag through our decision history, I thought it might be insightful to share the considerations being made on how do we go forward. So what are the perceived options? We see it as:

  1. Retain the deployment split and taken on the responsibility of maintaining the PIP
  2. As PDH is a discrete solution we could take the hit of adopting the Fusion Applications version of Product Data Hub and solve the synchronisation through the co-existence strategy
  3. Merge PDH into our main transactional EBusiness instance and remove the integration challenge by eliminating the need for it
  4. Build an alternate integration solution through the use of something like Golden Gate.

Clearly several of these options challenge the reasoning for separating the instances in the first place. So it is worth looking at the arguments for the separation and against it.

The key factors for separate instances:

  • System workloads in the transactional solution (for example end of month or year process runs) could impact user experience and productivity around the work of product data management. If this is the case and you can share the data but isolate the servers you will see a benefit
  • PDH and other hub solutions have dependencies on the core EBusiness suite, so if you want to capitalise on the improvements around the hub capability by upgrading, then isolating the instance minimises the upgrade depends considerations. If the hub was part of an EBusiness deployment with many components such as billing, manufacturing etc there is potentially a complex dependency chain to be resolved and upgrade activity that may become necessary with all the regression testing etc to be addressed with it.

The factors for keeping everything as one large EBusiness suite are:

  • The co-location of the hub and other features means that if you product authoring processes are complex and result in dependencies within the setup of other modules for example you want to align activities so buyers can both author the product data but also work with the purchasing processes you either have a multi phase authoring process – PDH to author the SKU which is distributed and then enriched within the other EBusiness instance of you end up with more modules in your hub instance and a data synchronisation challenge greater than can be resolved by the PIP.
  • remove the need for the additional licensed components – I.e. The PIP (therefore AIA foundation pack, SOA Suite, Weblogic,  OEM SOA Suite  monitoring etc).

The Fusion apps option creates some interesting questions. So the messaging around Fusion is that you can migrate from the non Fusion environments in a phased approach through the idea of co-existance (effectively data replication and transformation). However, despite the fact Fusion apps are maturing, the capability atleast here we’re told this green, although the migration process is well established as a mix of automation and manual process all packaged up as a consulting engagement. In addition to this the AIA Product MDM connector which supports EBusiness needs some small changes to work with the Fusion application.

Why even look at Fusion, aside from we know that Fusion is Oracle’s long term strategic product, from the information provided to us, it has a number of handy features for us that are unlikely to be retrofitted to the EBusiness product.

From AIA to SOA Suite 12c

10 Friday Jul 2015

Posted by in General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , , , , ,

Oracle has elected to move away from offering AIA Foundation Pack in its current form. Many of the features offered are being offered in a different packaging – predominantly SOA 12c Core Extensions, and some of the tooling which has not been heavily used will not be available in 12c.

AIA 11g Foundation Pack then it will be replaced by Oracle SOA Suite 12c Core Extensions via a SOA Suite 12c upgrade process for those who have already licensed it. The key consideration is the changes in feature availability in on premise upgrades and the ability to exploit all the tooling particularly into the SOA cloud is unlikely in the future.

Based on this we would recommended that any capabilities not offered natively in 12c should be retired from use, to remove potential issues as a result of upgrading or adopting  a  lift and shift cloud strategy. There is 1 possible caveat to this in the form of utilising the AIA canonical model, more on this  below. The sections shows how AIA capabilities have been re-aligned and you might move forwards.

A lot of the UI features have moved to products such as the Oracle Enterprise Repository (OER 12c) as a result the retirement of the Lifecycle Workbench and a few features have been retired.

Reference Process Models

Reference Process Models, are more aligned to the process of solution analysis and design. The capabilities here can be obtained from other tooling. Separating out process models from a product that is more technically aligned makes sense. We would recommend you want to look at process models in a solution independent capability – particularly as your processes maybe split across platforms and products and even between on-premise and the cloud.

Personally I have seen little use of the top down business process models wrapped up by AIA outside of prepackaged PIPs where process models have been considered they have been examined by business architects before determining by the technologists the delivery approach.

Common Objects

The canonical model piece is lost in the transition to 12c. The canonical model is presented through a series of XML Schemas and HTML documentation, so could be packaged up and continued to be used irrespective of of the SOA versioning – subject to ensuring no licensing constraint on where the schemas are applied that might prevent them being used in the SOA cloud for example.

If there are to be constraints around carrying schemas forward then a strategy of migrating to another broad canonical model such as OAGI  would be recommended. OAGI is particularly appealing given it strongly influenced AIA’s model but also their specialist domains leverage it as base definitions for example HR Open Standards.

Composite Application Validation System (CAVS)

CAVS provided a means by which it is possible to build integration tests that exercise composite components. This component could be leveraged by any Continuous Integration infrastructure. We have done this in the past before Oracle’s significant progress in adopting Maven and Hudson.

This is now part of the SOA Suite Core Extensions pack.

AIA Error Handling Framework (AIA-EH) including Resubmission Feature and Logging

This provides the common error management framework that can be extended to provide automated error handling – for example delay for a period and retry. This one of the most valuable capabilities offered in terms of functionality as it provides a unified framework on which you can do basic error trapping and retry to far more complex advanced capabilities. As part of 12c this has been advanced as well.

This is now part of the SOA Suite Core Extensions pack.

AIA Deployment Plans

Deployment plans tooling has now gone as the deployment mechanism (AID) has also been dropped. More on this below.

XSL Mapping Analyzer & reporting(XMan)

This tool provided the means to identify and understand how mappings have been customised or extended from base. This has been superseded by the Mapping Editor tooling in 12c which offers a better approach to this activity.

AIA Installation Driver & AIA Installer properties

This capability wrapped up a series of smaller WLST based processes to deploy a PIP either licensed or custom PIP. As the concept of custom PIP has been dropped in favour of a collection of composites and other artefacts as would be applied if building using just SOA Suite. The capabilities use within Specsavers’ has in the past been shown to be mixed with some people preferring the SOA deployment approach rather than the wrapped up AIA mechanism.

PIP Auditor

The PIP auditor was provided AIA 11g as a means to perform a health check on the configuration of a PIP including custom PIPs. Whilst  it is possible also include this tool into a Continuous Integration process  aide quality management it requires a lot of work to break the lengthy report into more manageable  . However this was not heavily adopted, and also not known to be used manually either, therefore the impact of not continuing its use is negligible.

Framework & Methodology

Still applicable as this is simply a set of architectural approaches utilising Oracle Middleware products such as SOA Suite

Project Life Cycle Workbench including AIA Artefact Generator

As a design tool this has been deprecated. However from a Specsavers viewpoint this has minimal impact as the workbench has not been heavily used in this form (this includes AIA Artefact Generator) as the elements can be generated manually by SOA during the development process.

As the above diagram shows, the life cycle processes are all underpinned by the development process itself.

With respect to the deployment of artefacts such as composites,DVMs etc this is still available through standard SOA mechanisms such WLST. Viewing deployed artefacts can still be done through various management consoles.

Oracle SOA Suite, AIA, PIPs and Fusion apps

23 Monday Jun 2014

Posted by in General, Oracle, Technology

≈ 1 Comment

Tags

, , , , , , , , , , , ,

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.

Impact on Integration when Moving to Fusion Apps

17 Tuesday Jun 2014

Posted by in General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , , , , , , , , , , , ,

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

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)?

Deployment of Fusion Apps with Non Fusion Apps

Deployment of Fusion Apps with Non Fusion Apps

Hopefully in the coming weeks we will get the opportunity to uncover answers with Oracle.