The Official AIA Blog

One of the frequently asked questions from those new to AIA or other canonical object based methodologies, is whether AIA is really needed in their specific SOA project.

In short, it depends.

Now, the longer version. AIA provides a robust platform and framework for business process driven, SOA based enterprise application integrations. If your business process already has a pre-built Process Integration Pack (PIP) available from Oracle for your specific enterprise applications, then it is a no-brainer to utilize the PIP.

For example, if you are implementing the Order to Cash process with Oracle Siebel CRM as the front-end system and Oracle E-Business Suite as the ERP system, then the Siebel CRM Integration Pack for Oracle Order Management: Order to Cash PIP should definitely be on your shopping list.  Even if the exact applications (or versions) are not a perfect fit i.e. say, you want the CRM integration to PeopleSoft or a legacy application, then you can start with the PIP and replace the Application Business Connector Services (ABCS) from the Oracle E-Business Suite to the other application. Compared to a 100% custom development solution, this provides you with all the benefits of a flexible integration framework and will be faster to implement since one end of the PIP has already been developed.

So the question “Do I really need AIA” only has relevance for business process driven SOA integrations for which there are no pre-packaged PIPs i.e. comparing use of AIA Foundation Pack (FP) vs a custom point-to-point development using Fusion Middleware. Now, the Foundation Pack is built on top of Fusion Middleware, so it must be providing value-add on top of it. Given my love for analogies, let’s take the following example.

Which is the faster, better way to build a plane?

I think everyone would agree that having pre-built components, engineered and tested to the specifications of what a plane needs, is a much faster and better way, than to do-it-yourself with basic raw materials, even if you have access to the same tools in both cases. The AIA Foundation Pack provides these pre-built components, that are engineered to the demands of EAI-based SOA integrations. It provides the pre-built components such as the Enterprise Business Objects (EBO), the AIA reference architecture and programming model, governance tools (e.g. service repository, integration scenarios) and framework utilities (e.g. error handling, message level testing).

So in the case of an EAI-based SOA integration, the answer is absolutely Yes, you do need AIA!

Now, I know many would argue, “but I am not really building a plane, I just want a one-time, quick, cheap solution, which may never need any enhancements”.  In this case, going the route of direct point to point integration using SOA may be sufficient, but not without risks.  Once you end up building a passenger train (the cheap, quick solution instead of a plane), which runs on a direct track - point to point between SFO and LAX - it becomes next to impossible to later turn it into a flying plane with the flexibility of going to multiple routes (NY) without a new track (point to point interface); and with a higher capacity and faster performance. In almost all cases, you would have to re-implement the project to start building a plane.

So the key is to be clear on the business needs and then plan for the right enterprise architecture to implement it. If the business needs a plane, go for AIA. Evaluate the use of native SOA technologies with point to point interfaces, only when it is absolutely clear - at all levels of management - that you are building a train.

The Agile PLM to SAP: Design to Release PIP was released as part of the AIA Release Vehicle 2.3. More details can be found in this datasheet.

From an AIA perspective, this PIP only goes to prove the value proposition of the architecture. The PIP was built based on the existing Agile PLM to EBS PIP based on the best practice “Design to Release” process. There was >70% reuse of the services that was created for the E-Business Suite PIP. The remaining 30% were specific to E-Business Suite and not relevant for the SAP integration, and only those specific SAP connectors had to be built. It took a partner only four months development time to build out those connectors and deliver this integration.  This not only reduced the cost of developing this integration but drastically reduced the execution risk by reusing services and following the design patterns using the AIA reference architecture.

Did you know that Oracle Application Integration Architecture allows you to build both loosely coupled and direct integrations to solve your data integration needs?

When data integration involves either a large batch of records, or very large data, it's pragmatic to consider a point-to-point integration specializing on the movement of data with high performance with a trade-off of reusability.

Point-to-point data-integration in AIA uses Oracle Data Integrator (ODI) to provide you with the best balance of performance and reusability. Through the use of Oracle Data Integrator (ODI) we create highly performant, high volume batch data-integrations with cross-referencing support that is reusable for all SOA integrations

Application Integration Architecture supports the following data-integration patterns.
• Initial Data Loads
• High Volume Transactions with XREF table
• Intermittent High Volume Transactions
• High Volume Transactions without XREF

To learn more about AIA techniques and patterns used to implement large volume bulk-processing integrations while supporting the larger SOA infrastructure, view our white paper: Bulk Data Processing and AIA

In an enterprise application integration scenario, SOA Governance is about visibility and control during the entire service lifecycle; including design time, where this boils down to maximizing the investments made in building the service portfolio to ensure that it provides for interoperability, reusability and extensibility. The AIA Foundation Pack allows you to satisfy these criteria using content and technical level governance.

Content level governance – the key to Interoperability and Reusability

The AIA Foundation Pack provides content level governance at all the abstraction layers. The Enterprise Business Objects (EBO) and Enterprise Business Services (EBS) development go through thorough scrutiny with Subject Matter Experts (SME) from each of the Oracle application areas (yes, including Fusion applications) to come up with a rationalized object model. It then undergoes a standardization pass, which ensures adherence to standards such as UN/CEFACT Core Component Technical Specifications (CCTS) and XML Naming and Design Rules (NDR). This level of governance renders the common object and services model instantly relevant as opposed to a theoretical model that is hard to implement, since it has been already vetted for mapping against most of the Oracle applications logical data models as part of the rationalization process.

Data models aside, the reason why the rationalization was even initiated in the first place is due to a compelling need at the business process level. The reference process models supplied with the Foundation Pack also allow you to drill down from the lowest levels of the process models right into the associated canonical objects and services. This allows you to now take your pick of the application capability that can best satisfy the business task at hand. Since the canonical layer has just “virtualized” your application capabilities, so you can start with the business problem instead of the constraints of the technology. This level of content governance not only relieves you from having to tackle with the typical SOA governance issues of having to decide on the right-sized service granularity, but it also creates a common platform for business and IT stakeholders to collaborate on i.e. shared semantics and a business process approach to integrations.

The content level governance just does not stop here, but goes deep into the implementation. Once the canonical objects are mapped to the actual application interfaces (Web Services, Component Interfaces, Interface Tables, APIs etc), these mappings can be then viewed using the XSLT Mapping Analyzer (XMAN) utility which analyzes the XSL maps and presents a tabular view of the EBO – Application mapping. In the case of Oracle AIA PIPs, custom extensions to the Oracle provided maps are highlighted which allows for easier identification during upgrades.  In addition, map reports from existing Oracle PIP assets can be viewed to assist in and accelerate custom Application Business Connector Service (ABCS) development as well as ensure that your custom maps are in accordance with the Oracle best practices. The tool can also be invaluable when comparing the same report from different transformations (potentially developed by different teams) to ensure that there are no mapping conflicts, which can be otherwise very difficult to detect.  (This is currently manual but in the process of being automated).

More on the XMAN tool can be found in this post.

Technical level governance – the key to Extensibility and Reusability

With an ever-growing asset inventory of design patterns and programming guidelines, manual checking for compliance to the AIA Integration Developers Guides standards checklist can get a little tedious. PIP Auditor is a tool designed to enhance productivity and improve the quality of the services by checking your AIA services for compliance to programming best practices and patterns found in the AIA Integration Developers Guide, as well as other industry best practices as appropriate.

The report output is categorized per TOGAF standards and a compliance “score” is presented. Developers can drill down into the problem areas and identify the areas to fix in order to achieve compliance.

Violations can be drilled down into right down to the file level and where relevant, even even down to the line/column number e.g. in the case of naming convention violations.

The design of the tool is flexible enough to allow for incremental patching of new rules – more than 70 rules have already been implemented as part of an internal beta release, with more coming soon before we make it available on Metalink.

More on the PIP Auditor tool can be found in this post.

There are a lot more productivity enhancing tools and utilities that are available as part of the AIA Foundation Pack, such as an Artifacts Generator and a Build Install Generator tools, which we will be discussing on this forum in future posts.

Many a times we have a question on AIA. It may be a how-to kind of question, detail on particular product feature etc.,  or just curious about latest on AIA. Often this information is available, but we may not know where to look for.

There are scores of information available on AIA through various sources such as OTN, Metalink, Guides, White Papers, Blog articles etc. Few places to start are:

• The official AIA site
• AIA Documentation Library on OTN - Release notes and guides on various AIA releases
• AIA Resource Library - Podcasts, videos, whitepapers, webcasts and more …
• AIA on Metalink - AIA knowledge base on released products, guides, patches, service requests, various how-to and reference articles. You may either search on all of AIA or limit it for a specific Foundation Pack or PIP.

There is some interesting information available on Metalink such as, EBO Implementation Maps for Oracle AIA Release Vehicle 2.4, Installing AIA on Cluster, AIA Developer Tools, Platform Certifications and AIA etc.

• AIA on E-Delivery – AIA products download by platform.
• AIA Forum - Ask questions, give feedback, discuss issues and exchange ideas related to the AIA Foundation Pack (FP), Process Integration Packs (PIP), the underlying technologies, architecture, best practices and methodologies
• And of course, this AIA Blog :)

Conversion between timezones of the participating edge applications is required when the integration specific logic or the data being exchanged involves date with timestamp attributes.

In Oracle EBS, DATE fields do not store timezone information and are supposed to be in EBS server timezone. In all UI transactions, it is assumed that the EBS User Interface will convert from User (client) TZ to EBS server TZ while pushing data into db, and from EBS server TZ to user TZ while pulling out data from db on to the UI.

The same principle can be applied for AIA based interface with EBS. In AIA Provider ABCS, AIA layer (client for EBS) should first query the EBS server TZ or have it as a configuration property (there already exists a "Ebiz" module property EBIZ_01.SERVER_TIMEZONE in AIAConfigurationProperties). It should then convert the incoming xsd:dateTime value in the EBM to EBS server TZ, and then pass the converted date value to EBS APIs as a DATE field.

To convert between timezones, EBS Integrations has developed and made available a generic custom XPath function ebi:getConvertedDate() which has been used in a couple of PIPs; similar methodology can be adopted in other PIPs. To get TZ from xsd:dateTime field, a bpel function can be used - timezone-from-dateTime(). In order to get EBS server TZ, following query can be used:
select timezone_code from fnd_timezones_b
where upgrade_tz_id = fnd_profile.value(’SERVER_TIMEZONE_ID’);

[While calling EBS APIs using Oracle Apps Adapter, currently EBS doesn't support timestamp with timezone type in PL/SQL API signatures. So the dateTime field (including TZ) in Enterprise Business Message (EBM) cannot be directly mapped and passed to EBS API. Even if one tries passing a date with timezone to a DATE field in PL/SQL, Oracle Apps Adapter does an automatic timezone conversion to the timezone where the JVM is running which can lead to incorrect results.]

Similarly, in Requestor ABCS, while retrieving data from EBS, AIA layer should query the EBS server TZ, and then convert the retrieved DATE from EBS server TZ to EBM/AIA TZ. The EBS wrapper API can be made to return in GMT always, or it can be made to return in a specific TZ(configurable at AIA layer) passed into it as input parameter. In case of direct query from db, the SQL can be written to return the date value in GMT or in the configured TZ.

Oracle EBS supports UTF-8 characters and hence the PIPs involving EBS as a participating application would normally be a candidate for being MLS (Multiple Language Support) compliant. All language specific operations in EBS are done based on EBS User preference settings and hence through FND APPS context.

In EBS Provider flows, the data sent into the PL/SQL API gets inserted/updated into the user's language specific row in TL tables. So AIA layer needs to set the FND APPS context or use the correct integration user in Oracle Apps Adapter. This can be done based on EBM Header's language code using which we can set the integration user dynamically, say using a DVM or some configuration mapping.

In Requestor flows, again an EBS API returns data in one language at a time. Most of the EBS APIs return data based on the user preferences set in FND APPS context. So AIA layer needs to set the FND APPS context or use the correct integration user in Oracle Apps Adapter for each language, and then call the PL/SQL API.

For EBS Interface tables, generally no language specific rows are maintained for transaction data i.e. whatever data gets inserted into the Interface table, the same data is pushed into the EBS product tables based on User language set in the calling session. So AIA layer just need to insert data into the Interface table, and then before calling the Concurrent Program or any post-processing API, FND APPS context need to be set.

Many newcomers to AIA and canonical models get overwhelmed with what information needs to be populated on the header. In Integration Developers Guide (which can be downloaded from metalink number 824495.1 or use this URL https://webiv.oraclecorp.com/cgi-bin/webiv/do.pl/Get?WwwID=note:824495.1), under the heading, Populating the EBO Object Identification has details on populating identification structure.

Below section describes Identification structure usage.

1. BusinessComponentID - This is a unique key for the application agnostic representation of the object instance. This is generated by the API provided by the Oracle AIA infrastrucutire. Within XSLT you would call populate XREF API to generate this key value. Hence these values will be stored in XREF table.
2. ID/ContextID - This is the business friendly (i.e. the one that has business context identification) identifier present in the participating application for this particular object instance. For example, PO number and Sales Order number.
3. ApplicationObjectkey - This is the Primary key of the participating application which is internally generated unique key for this particular object instance. For example, PK-Order-ID or Worker_ID.
4. AlternateObjectKey - Different ways of Identifying the same object instance. Use this element to capture additional information about the key. For example, GrouID in General Ledger entry or CONSECUTIVE_BILLING_NUMBER in Invoice. Not all Identifications may have this field populated.

Further, to define the environment in which an identifier is valid, a set of attributes that describes the validity of the key is supported in addition to the actual key value.
1. schemeID - Attribute schemeID provides information about the object type identified by the ID, for example ItemGUID for the GUID of an item and PartyGUID for the GUID of a party. For the BusinessComponentID, the schemeID is set to the name of the object followed by ' GUID'. For the ID, the schemeID is set to the name of the element as known in the participating application.
2. schemeVersionID - This describes the version of the identification scheme.
3. schemeAgencyID- This is the ID of the agency that manages the identification scheme of the identifier. The GUIDs generated by Oracle AIA will have AIA 01 populated in this attribute. For identifiers generated by participating applications, the short code for that of the participating application will be stores in this attribute.

If there are multiple instances of a packaged application that has the same business capability in a customer eco system, how many ABCS connectors do we need to integrate them?

The answer is, regardless of the number of application instances for a packaged application, AIA recommends to build only one ABCS connector for that packaged application to perform a specific business task.

It is the responsibility of the routing rules defined in the EBS that will orchestrate the message to the appropriate instance of the application.

Here are some of the best practices that are adopted by Oracle PIP Developers. If you are new to PIP and want to know what to look for when mapping Enterprise Business Message (EBM) in your XSLT transformation, please follow below best practices.

Dos:
 Select EBO based on Business Concept and not based on number of fields that match.
 Use Specification group cautiously, avoid if possible.
 Customize EBO for missing fields/Business Concepts
 Use Predefined corecom: prefixed Elements or DataTypes for customization.
 Refer to XMAN reports for understanding XREF/DVM and functional mapping of existing connectors
 Map Flags to Indicator types.
 Map fields semantically.
 Signup for FP and 2 day EBO training.
 Use appropriate Operations (EBMs).

Don'ts:
 Do not map just based on Data types
 Do not map just based on field name.
 Avoid creating your own data types.
 Don't Customize if Custom stub is not present.

One of the challenges in SOA implementation is visibility of SOA artifact inventory. A limitation in visibility will limit service reuse. To promote visibility of SOA artifacts i.e. Foundation Pack (FP) and Process Integration Pack (PIP) artifacts, AIA provides BSR (OER in FP 3.0). BSR allows you to search for services and other artifacts from a top down perspective. However, in many instances a top-down approach may not solve the problem and you may want to adopt bottoms-up approach. To aid PIP developers and analysts alike, AIA provides another tool which is called as XMAN (XSLT Mapping Analyzer). XMAN is a tool that introspect the mapping structure in complex XSL transformation and presents a user friendly report in HTML and CSV format. You an down load this tool from Metalink

The report shows ABM (Application Business Message) X-path , DVM (Domain Value Map), XREF (Cross-Reference) and EBM (Enterprise Business Message) X-path. A sample report of XMAN -