The Official AIA Blog

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

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.