The Official AIA Blog

Creating DB schemas in default tablespace is frowned upon by most DBAs. Foundation Pack creates two schemas as part of its installation. 1. AIA schema 2. JMSUSER schema. These two schemas are created in default tablespace of the Database. Quite a few times I received dejected emails from end-users, complaining that FP installer neither allows them to decide where they want to create the schemas nor allows them to input pre-created AIA schemas. That’s not fully correct. In fact, there is a workaround.

Create two schemas with aia/aia and jmsuser/jmsuser credentials (passwords can be changed post install). Create the schemas in the tablespace as desired by you. Then launch FP installer, and provide the same database details. In the install log you would see below error:

Executing commands
[sql] Failed to execute: create user aia identified by aia
[sql] java.sql.SQLException: ORA-01920: user name 'AIA' conflicts with another user or role name
[sql] 7 of 8 SQL statements executed successfully
[echo] ----Creating jmsuser database schema--------------
[sql] Executing commands
[sql] Failed to execute: create user jmsuser identified by jmsuser
[sql] java.sql.SQLException: ORA-01920: user name 'JMSUSER' conflicts with another user or role name
[sql] 5 of 6 SQL statements executed successfully

Don’t panic! This error is not malicious. Your FP Installer will use the existing users created by you.
You can use this approach on almost all AIA products from AIA for Comms 2.0 to AIA FP 2.3….even for Cluster installations!!

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.

AIA is just shy of 2 years old and already we are seeing tremendous customer adoption and traction. It's exciting to be part of a team that continues to grow despite the current economy. Part of the reason for AIA's success is that with all the cost-cutting that is going around, smart companies are actually investing in areas that can generate near-term efficiencies and revenue growth.

Business processes around Pricing and Sales, Sourcing and Production, Customer Service and Support, are low-hanging fruit for strategic investments in optimization and automation.

Amway, Ciena, Pella, Lyse Energi, BaneTele, Vodafone Qatar, Com Hem and Zebra Technolgoies are just a few of the customers that are using AIA to reap cost-savings and efficiencies with Oracle AIA.

Earlier this month, Oracle announced how AIA helped Zebra Technologies rapidly integrate Oracle Master Data Management to Siebel CRM and two existing legacy ERP systems on time and under budget.

“Zebra Technologies has experienced rapid and extraordinary growth as a company, but all of our disparate systems and applications were not meeting the business’ needs or value required,” said Don O’Shea, CIO, Zebra. “One look at Oracle Application Integration Architecture and Oracle Master Data Management made us realize we had found our key to solve a massive problem.

Amway is also using AIA Foundation Pack to consolidate and modernize their global IT infrastructure.

"We needed to unify our application infrastructure to support our network of over three million independent business owners in over 60 countries and territories around the world," said Tina Abdoo, Manager of Application Development, Amway. "With Oracle Application Integration Architecture driven by AIA Foundation Pack, we have been able to consolidate systems that were created from decades of high-maintenance legacy code, while also supporting and enhancing our broader SOA initiative. This has enabled us to achieve a faster, structured and repeatable approach to process composition that improves and extends the business impact made by our enterprise applications."

Companies like these that take advantage of shifting market dynamics to become more flexible in the face the change will ultimately come out ahead of those that focused on pure cost-cutting initatives, and find themselves with larger returns and margin enhancements in the long run.

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

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.

Robust error handling is an integral requirement for all integrations. AIA Error Handling Framework allows capturing any error happening in the integration scenario in a consistent manner. However, there are scenarios when it is not sufficient to capture the error message but we also need to capture the specific details of the failed business message, such as the Order Processing scenario where there is a need to capture the details of the failed orders and log tickets in the Trouble Ticket application. This can now be achieved with extending the AIA fault message and have custom processing on certain failed messages.

Foundation Pack 2.3 comes with enhanced capabilities to extend Error Handling Framework. The extensions target two key areas:
1. Fault Handler Extension and enrichment of Fault Message
AIA Fault Message have a new element, ApplicationFaultData of type xsd:any. This can be used to hold any Fault Message enrichment as desired by the application context. For example, Order Fallout related information specific to a certain order. PIP implementations can extend the default AIA Fault Handler and plug-in their custom handlers to enrich the faults occurring in any scenarios.

2. Notifications Extension
Default AIA Error Handling Framework does email notifications and assign tasks on Error Console. At times there is a need to do something more such as pushing faulted instance details to custom trouble ticketing applications or to do custom notifications. Each PIP implementation requirements are varied and use cases have broad range.
Foundation Pack 2.3 provides the capability to stamp custom JMS Correlation IDs on each faulted message through simple UI interface. PIP Implementations can have custom listeners on AIA_ERROR JMS Topic to pick messages that need custom processing.

Detailed information can be found in AIA Foundation Pack 2.3 Guide

Oracle is hosting a free virtual conference, Wed, March 11. It's a really interesting concept. Attendees will be able to "attend" keynote and track sessions, visit booths, talk to product teams, etc. just like at a real conference, except all online.

The theme of the event is "Turning Challenges into Opportunities: New Strategies for a New Global Economy"

If you're interested in learning more about AIA, please join us online. We will have sessions and product teams available for you to interact with.

Wednesday, March 11, 2009
8:00 a.m. – 2:30 p.m. PST

Register today!
https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=132016&sessionid=1&key=74FD72AB4B173B9EC4EB82C0051CDA35&partnerref=oracleevite1&sourcepage=register

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.

People often ask me if AIA really provides a strategic solution to reducing integration development cycles, costs and improving quality of service and consistency.

Based one what we are hearing from customers, the short answer is a resounding, "Yes!".

If you are looking to consolidate your application integrations on a standardized platform and/or move to SOA, AIA Foundation Pack is the way to go. Customers are telling us that AIA Foundation Pack has helped accelerate efforts by anywhere from 20-30% because of our prebuilt content. (For the sake of legal, I better temper this by adding that individual results may vary.)

A lot of this is attributed to our Enterprise Business Objects and Enterprise Business Services, which are core to what makes AIA so special and where customers are seeing real value. Many of our global customers have tried to build objects themselves. In the end, their experiences have taught them that they would much rather hand this onerous task over to Oracle. A frequent quote is "I wish AIA was available when I first embarked on SOA years ago..."

If you are not familiar with our EBOs/EBSs, the beauty of them is that they are not specific to any application because AIA is designed to be application agnostic. So what you get is a non-proprietary framework to integrate ANY application within your portfolio. This is where the real challenge comes into play, right? It's one thing to integrate Oracle to Oracle apps and an entirely different beast when it comes to integrating legacy apps that have absolutely nothing in common with each other.

So whether you are integrating Oracle applications with FP, or plan to integrate non-Oracle apps to each other, consider AIA Foundation Pack. Either way, you will reap the same benefits of resuability, configurability, extensibility, cost savings, reduced risk, and faster time to value. It's a win-win situation.

On 08.08.08, Oracle announced the release of Design to Release Process Integration Pack (D2R PIP). There were fireworks in Beijing, though legend has it that they were to celebrate the beginning of some sporting event.

The D2R PIP enables a bi-directional synchronization of product content information between PLM systems (like Oracle Agile PLM) and manufacturing systems (such as Oracle E-Business Suite), and is built leveraging AIA 2.2. Almost every company that uses Agile PLM also uses an ERP system. Irrespective of the ERP system used, the integration requirements are more or less the same:
• Engineering designs are mastered in PLM
• The NPI process releases those designs to manufacturing, where they are costed, transacted and planned for
• All future design changes are also mastered in PLM and similarly released to manufacturing using revisions made on change orders
• Engineering needs access to costing and planning related information from ERP to make decisions on part usage and design phase-in

One of the primary design objectives of the PIP has been to make customers self-sufficient in maintaining and evolving the PIP without having to hire external consulting help. The PIP is designed from the ground-up to maximize configurability and customizability for widely varying manufacturing environments without requiring a change to the base code of the integration. Extra emphasis has been placed on user-friendly exception handling, and ease of detailed drilldown troubleshooting for IT.

What is little known is that the PIP was developed using an "Adaptive Business Solutions (ABS) guided" methodology - this means that the development work was done not by the AIA team, but by other product teams and a partner (Satyam) using standard guidelines published by the AIA team and solution architecture support from the AIA Guided Development team in a consulting role. This is a landmark achievement because it demonstrates beyond doubt the high level of maturity of the AIA platform and development methodologies around it, and its readiness to be adopted by customers and partners for building their own portfolio of integrations, analytics and composite applications.

Download this datasheet to read more about the D2R PIP, and to view some screenshots.