Tag Archives: OER

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.

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.

Oracle Fusion Applications Development and Extensibility Handbook – Chapters 13, 14 & 15 reviewed

12 Saturday Apr 2014

Posted by in Book Reviews, Books, General, Oracle, Oracle Press, Technology

≈ 1 Comment

Tags

, , , , , , , , , , ,

Our final detailed visit to  Oracle Fusion Applications Development and Extensibility Handbook (Oracle Press) covers the final 3 chapters which engage with the Scheduler, Look and Feel customisation and the relationship with integration and service concepts (dare I use the acronym SOA).

The chapter on the scheduler is pretty short, but then compared to many other chapters the size of the product/component is small. The book relates how the scheduler behaves compared to the Schedule Management offered in EBusiness. The surprising things is that each product domain (Financials, HCM, CRM etc) has its own scheduler rather than a single shared service; the book doesn’t attempt to explain the rational here which is a shame.  It does describe how it deploys into each domain, where the configuration exists and how to work with the configuration of the scheduler itself (e.g. where logging goes etc) and attempts to address some obvious questions from a administration perspective.  It then goes onto how to create a custom scheduled process with a worked illustration. All very well done, although I have to admit to a nagging feeling of I’m missing something – it maybe simply that deployment is very much through server administration rather than through an automated mechanism (so if you develop and test in a preproduction environment, you can package up the process of deploying config custom app to your production environment without needing to repeat the admin UI interactions, so you can be assured there is no inconsistency between deployment instances).

The Look and Feel chapter is about largely applying the changes so that the product feels like part of your business’ corporate solution – important if you’re exposing any aspects of it to the outside world. So aside from the use of the tools you have the ADF controls to effectively ‘skin’ the product. The chapter provides a brief but concise view of how skinning works, in relation to the old EBusiness technologies (CLAF and UIX) and current HTML technology of CSS and the key part of ADF (Rich Faces). More importantly it points out the relevant documentation on all the sources of information, and tooling such as the skinning editor. Not to mention addressing the issue of deployment. Obviously there is a short illustration demonstrating an element of skinning.

ADF Architecture

The initial emphasis on the last chapter is the reality that organisations can’t simply migrate all non Fusion Apps such as EBusines, Seibel etc to the Fusion solutions in one hit therefore you need to provide a degree of integration between solutions for as long as the transition may take. This neatly leads into the question of well how do I know what components exist to support integration, which brings OER (Oracle Enterprise Repository) into the picture. So obviously the book provides a brief overview to the use of OER. The various Fusion apps offer different interfaces for different tasks (from bulk data export to business events) so each of these ‘patterns’ are briefly explianed and as Fusion apps is offered as a SaaS solution how that might impact the ‘pattern’ availability. The chapter finishes by walking through the use of using a SCA Composite and web services to interact with a Fusion App – probably one of the most common approaches to integration at a transactional (rather than bulk) manner.  The only thing missing for me would be a brief discussion on Process Integration Packs (PIPs) which leverage all of  the technologies underpinning Fusion Apps into a custom package of integration operations or ready made integrations.

So the final chapters provide a strong close to the book continuing to offer an excellent overview, pointing you to resources to ‘deep dive’ as necessary.

 

Previous Chapter reviews: