The Official AIA Blog

The AIA Enterprise Business Services (EBS) represent the core business functions of an enterprise as they interact with the wider ecosystem of enterprises as part of day to day business interactions. They are not web services exposed by any business software application implemented in an enterprise.

Let me elaborate further. In any enterprise, we always find multitude of software applications implemented. This is mostly by design. Running a business is complicated and it is challenging to keep up with the competitors. In their quest to excel, enterprises seek best of the breed software applications evaluating their core functionalities. Thus an enterprise ends up with different software applications catering to Customer Management, Product Management, Asset Management, Order Management, Financial Management and so on. The stove pipes of applications are more narrower in scope, in reality.

The web services or APIs exposed by these software applications are granular in nature and represent their core functionalities. These applications need to be integrated in order for the enterprise to carry out the core business functions. For each of these business functions or tasks to be accomplished, multiple applications with their granular services need to participate.

The AIA Enterprise Business Services, representing these business functions or tasks, mediate the invocation of the granular web services between various participating applications.

Needless to say, the payloads of the AIA Enterprise Business Services are Enterprise Business Messages (EBM) and these represent the canonical data models of the industry in which the enterprise is doing business. They are not hostage to the participating application data models.

More on Enterprise Business Messages and Enterprise Business Objects (EBO) in next post.

The Enterprise Business Messages are the packets of data which the Enterprise Business Services accept from requesters and route to providers. They carry the pieces of data needed for the requests to be understood and serviced. Needless to say, these are unique to the industry the enterprise is in business and their structures have evolved over time. As I said before, they are hostage to no application.

An application finds its way into an enterprise because of its unique ability to address specific business requirements. In the process of developing this ability, the application comes up with unique data structures.

The Enterprise Business Messages (along with the Enterprise Business Objects) empower the enterprises to evaluate the applications and transform the disparate data structures (and underlying concepts) of these 'best of the breed' applications into enterprise concepts driving their business processes.

Thus an Order Capture application would have Order entities to capture the order while a Billing application may have ability to enable billing in Customer entities for the services rendered. A service industry specific Sales Order EBM would have the structure to represent the Order captured for a Customer in Order Capture system and turn it into Customer in a Billing system with billing enabled for the services rendered.

In AIA, we talk about extensibility for Enterprise Business Objects, XSLTs, BPEL processes and also ESB Routing Rules.

But what about Enterprise Business Message and Enterprise Business Service?

Lets look at Enterprise Business Message first.

Since an Enterprise Business Message is assembly for schema components, extensibility would mean a new EBM. The solution is to create a new EBM xsd containing the required EBM definitions.

For example, lets say there is ItemEBM.xsd which has CreateItemEBM, UpdateItemEBM and QueryItemEBM. There is a need for DeleteItemEBM and ValidateItemEBM. To extend the ItemEBM.xsd, create a CustomItemEBM.xsd and include in it the definitions for DeleteItemEBM and ValidateItemEBM.

Similarly, extending Enterprise Business Service would mean adding new operations. This can be accomplished by creating an extension EBS (a new ESB routing service), for holding the customer specific operations. This newly created ESB routing service can either use the same EBM or the newly created EBM (for housing the Enterprise Business Messages for these new operations). Since these are newly created entities, they are totally upgrade safe.

So, ItemEBS continues to support the standard CRUD operations and is based on the shipped ItemEBS.wsdl. For a custom operation, you need to

• Create a new wsdl file CustomItemEBS.wsdl defining the interface / contract including the operations
• Create a new ESB project containing a routing service CustomItemEBS pointing to your new wsdl
• Deploy the CustomItemEBS

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.

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.

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.

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!!

I notice quite a few times that FP installation fails because of issues with SOA suite and DB and I hear queries on how to make sure SOA Suite is ready for Foundation Pack installation.
Make sure your answer is ‘YES’ to all of the below questions. This might not be an exhaustive list of pre-requisites, but will certainly eliminate most of the common errors.

1. Are you using the right version of JDK?.
Each version of Foundation pack is certified with a different version of JDK. Verify the installation guide and metalink notes to check for the most recent version. The last version of Foundation pack was certified on JDK 1.5 update 16

2. Does the DB user have DBA privileges?
The DB user entered during interview screens should have privileges to create a db schema. ‘sys’ user usually has all the required privileges.

3. Is directory browsing enabled on the server?
Check the install guide for information on how to enable directory browsing on your server.

4. Is your ESB working properly?
a. Ensure ESB design time and runtime are accessing the following urls.
http://host:port/esb/dtStatus.jsp
http://host:port/esb/rtStatus.jsp
both the pages should return a true.
b. Deploy a sample ESB process from ESB Console and execute it to check the results.
c. Create a sample ‘system’ from ESB Console.
d. Ensure virtual host and port of BPELSystem and DefaultSystem are set appropriately in ESBConsole.

5. Is your BPEL PM working properly?
a. Deploy a sample BPEL process and verify the flow eg: LoanFlow demo.
b. Verify if you are able to login to BPELConsole and navigate across various pages

Note: remember to undeploy the samples and delete the previously created system.

6. Verify that you don’t have any existing applications in your SOA cluster starting with “default_”.
For example if you had deploy the LoanFlow demo, it would’ve created such applications.
To check this
i. Open the EM Console
ii. Navigate to the container
iii. In the Applications tab, drill down from BPEL>orabpel.
iv. Select any application starting with “default_” and undeploy

In a typical SOA deployment, there are a number of services deployed and thousands of messages exchanged on any given day. Howsoever we design our services and optimize the service deployment infrastructure, exceptions do happen. These exceptions can be broadly categorized as System Faults and Business Faults.

AIA Error Handling Framework captures all the exceptions in a consistent manner and provides notification capability out of the box to notify appropriate people about the exception. This enables them to analyze the exception and take appropriate corrective action.

AIA Email notifications can be configured in as little as 15 minutes following these 4 steps;

1. Define appropriate Users and Roles

For a given exception, the service SLA may require you to notify different users. You may need to notify different people for system errors, network issues etc. and different people for business errors such as data validation or CreditCheckFailed etc. AIA provides an XML based user repository (JAZN), but you could also configure your existing user store such as LDAP to define various roles of system users, integration admin, participating application admin etc.

If you are using JAZN,

• Update “$SOA_HOME/j2ee/oc4j_soa/config/system-jazn-data.xml” file to define roles and users. AIA defines default AIAIntegrationAdmin role and AIAIntegrationAdminUser out of the box.
• Update “$SOA_HOME/bpel/system/services/config/user-properties.xml” file to populate various attributes for these roles and users. Ensure to provide a valid email address for your domain.

2. Associate Roles to a specific Exceptions

AIA provides ability to notify different roles based on process name, service name, system id and error code. You can setup these notifications on AIA Console -> Setup -> Error Notification screen. For more information, see Oracle Application Integration Architecture Core Infrastructure Components Guide, "Setting Up Error Notifications for Oracle AIA Processes". It also explains the logic used to determine notification roles for an error.

If no appropriate role is defined for a certain error, AIA notify the default role (AIAIntegrationAdmin) defined in AIAConfigurationProperties.xml file.

3. Configure Email channel

Update “$SOA_HOME/bpel/system/services/config/ns_emails.xml” file;

• In the <EmailAccounts> element, set the “NotificationMode” attribute to “EMAIL”, instead of “NONE”.
• In the <GeneralSettings> section, set the <FromAddress> to a valid email address for your domain.
• In the <OutgoingServerSettings> section, set the correct <STMPHost> and <STMPPort> for your domain.
• Comment out <IncomingServerSettings> section if you do not have a need for it.

4. Restart BPEL Process Manager

Now you should see email notifications triggered for every error in the AIA system.

Oracle SOA Suite 10g supports five channels of notifications, Email, Pager, Fax, SMS and Voice. AIA provides an implementation for Email notifications, but it is easy to configure any other channel and provide custom notifications if needed.