An Oracle White Paper

April 2013

Implementing the Agile to EBS Design to Release Integration:

Setup

-1-
Disclaimer

The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing decisions. The development, release, and
timing of any features or functionality described for Oracle’s products remains at the sole discretion of
Oracle.

-2-
Preface
The Implementation Guide for the Agile to EBS Design-to-Release Integration contains information related
to the setup and configuration of Agile, EBS, and the AIA layers. Agile and EBS are highly configurable,
and if either or both are configured, the Integration must also be configured to function as desired.

Goal of this Document

The purpose of this document is to supplement the Implementation Guide information related to setup of
the Agile to EBS Design to Release Integration. It is not intended to replace the information in the
Implementation Guide, rather to explain in further detail the setup steps required. Also, this paper explains
some of the setup required when Agile or EBS is highly-configured.

-3-
Table of Contents
1. About Agile settings related to the PIP.................................................................................................5
1.1 Creating Destinations for PIP use....................................................................................................5
1.2 Events for ECO, MCO, and SCO....................................................................................................6
1.3 Filter settings...................................................................................................................................7
1.4 Subscriber Settings..........................................................................................................................8
1.5 Setting Privileges.............................................................................................................................8
1.6 About the Change_Status table for workflow.................................................................................9
2. About settings related to E-Business Suite...........................................................................................9
2.1 Profile Settings...............................................................................................................................9
2.2 About the APPS schema..................................................................................................................9
2.3 Concurrent Programs.......................................................................................................................9
3. Settings related to Middleware (AIA).................................................................................................10
3.1 Setting up cross reference data.....................................................................................................10
3.2 Setting up Domain Value Maps.....................................................................................................10

-4-
1. About Agile settings related to the Integration
The Implementation Guide contains specific instructions on how to set Agile up related to the Integration.
The following information is to further explain the settings, and provide some additional insight on what may
need to be tuned in your environment to make best use of the Integration. Please refer to the
Implementation Guide for exact navigation on the setup steps, as it will be the one point-of-reference for
this information. Agile is the source for the most-used flow in the Integration, the Change Order release.
Whether it is an ECO (Engineering Change Order), MCO (Manufacturing Change Order), or SCO (Site
Change Order), the logic is basically the same.

When these settings are configured, when a Change Order is in ‘released’ status, Agile will send an ATO to
a JMS Queue on the AIA SOA Server, which serves at the trigger for the rest of the flow. These settings
are described in the Implementation Guide, but are further explained below:

1.1 Creating Destinations for Integration use

The Implementation Guide contains instructions detailing how to set up the destination within Agile PLM.
Please note the following additional explanation and helpful tips:
1. If Agile PLM is running on Oracle Application Server (OAS), there is an additional step that must be
performed before you set up the destination. The reason for this additional step is that a
Weblogic thin client must be installed on the OAS in order for OAS to successfully communicate
with the JMS Destination on the AIA Weblogic server. If you skip this step using OAS, the Agile ACS
will not be able to communicate to the AIA Weblogic domain, and all of the ATO’s will fail.
2. There is a note in the implementation guide regarding the setup of “Cross-Domain Security” or
“Global Trust” on both the AIA Weblogic domain and the Agile Weblogic domain. One of these
(BUT NOT BOTH) must be setup accordingly. This is very important to set up correctly. It is
possible for the destination test to be successful from the Agile Java Client, but for ATO’s sent to
that destination to fail. The reason is that the test is performed from the Java Client itself, and
ATO’s are sent from the Agile Weblogic Server. If the AIA Domain does not “trust” the Agile domain,
it will refuse the connection to the JMS Destination and no ATO’s will be able to process. This
problem is very hard to diagnose, as the only error visible in such cases is in the console where
the Agile server was started – an error is not generated in any log on the Agile side. The
destination test is very useful, however, in determining that the values you specified for the
destination are correct. The process for setting this up is documented in:
http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/domain.htm#i1175685
Under the heading:
Enabling Cross Domain Security Between WebLogic Server Domains

-5-
 3. If the destination test fails, it is useful to go through the exercise of verifying each field that you
entered is correct and contains no whitespace. This can be a problem if these settings are pasted
from another document. Even a space at the end of the Connection Factory name, for example,
will cause the destination test to fail. To verify the settings, you can log into the AIA Weblogic EM
Console to make sure the names and paths are correct and exist.

Verify there is no whitespace in the highlighted areas

1.2 Events for ECO, MCO, and SCO

The events define when an ECO is pushed to AIA for processing. You need to create a total of 6 events; 3
for the CO Release process and 3 for the CO validation process (one for each: ECO, MCO, and SCO).
The difference between these filters is what ECO status is used to fire each flow.
1. For the CO Release flow, the status should be “Released”.
2. For the CO Validate flow, you can use any status other than released. Normal practice dictates this
should usually be set to “Submitted”.

-6-
1.3 Filter settings
The filters control what information is placed in the AXML message that is sent to AIA. Consequently, this
is the most important Agile setup step to pay attention to when it comes to tuning your environment for
optimum performance. The idea is to include the details you need and exclude the ones you don’t. The
importance of tuning the filters cannot be understated – there can be as much as a 100% improvement in
the processing time and resource use. These settings, along with the AIA SOA tuning (later in this
document) can mean the difference between a very large ECO processing successfully or failing. You
must set up a total of 4 filters, one for items, and then one each for ECO, MCO, and SCO. The following
information deviates from the Implementation Guide, and should be followed with the advice of someone
familiar with the functional side of your Agile implementation.
1. For the Item filter, View Tabs: Only include the values that you want included in the AXML message
to AIA. For example, if you do not use any page three fields, omit the “page three” value from the
list. Likewise with page two and sites. If you do not use these fields but include them here, it will
still increase the size of the message.
2. For the Item filter, BOM Levels: For optimum performance, uncheck the “All Levels” box and set
the level to “1”.

Check the highlighed areas to make sure they are consistent with what you want to transfer in your environment.

-7-
1.4 Subscriber Settings
The Subscriber serves as the “link” between the Filters you have defined and the Destination you created.
You have to create one for each type of change order: ECO, MCO, and SCO.

If you plan to implement the validate flow, you will need 6 subscribers, 2 for each type of Change Order: ECO, MCO, and SCO

1.5 Setting Privileges

Modify privileges must be set according to the implementation guide for all 3 categories of change order
(ECO, MCO, and SCO). Please be sure to pay careful attention to all of the details related to the privilege
selection, making sure to double check the invisible/disabled attributes are selected. Also take note that
you must set up privileges for both modify AND create.

-8-
1.6 About the Change_Status table for workflow
Please take care to set up the Change_Status table included with the AIA Integration to reflect the Change
status you want to use in your system. It will be empty upon installation. The process for setting up this
table is in the implementation guide, be sure to follow all the steps carefully. The value in this table is what
the Integration uses to trigger the flow. It is compared to the current status of the ECO in Agile (“Released”
for the release ECO flow, for example). Setting this table up incorrectly (not in accordance with your
expectations) can cause the validate ECO flow to trigger instead of the release ECO flow, and vice-versa.
Also, the flow may not execute at all (depending how the rest of the system is configured).

2. About settings related to E-Business Suite

The E-Business Suite does not require as much setup as Agile, mostly because it is on the receiving end of
the most-used flows. Three flows are initiated from E-Business Suite through concurrent programs, and
must be set up as such, but most of the setup involves configuring the system such that the data received
is handled properly and the correct privileges are set up to allow the data to be placed in the correct
location.
Most of the errors that occur in the E-Business Suite provider due to incorrect setup are very vague, and
require a good deal of diagnosis and log examination to determine a cause. Due diligence during the setup
will ensure this is kept to a minimum, saving quite a lot of time.

2.1 Profile Settings

Specific profiles must be enabled in E-Business Suite in order for the Integration Flows to execute
successfully. Failure to set the profile options correctly will result in errors in the flows when they are
executed that may not be apparent when the Integration is initially tested (some profile options are only
used in certain circumstances). Additionally, most of the errors given will be difficult to diagnose, as they
will require running the failing flow with Ebiz tracing enabled, and then analyzing the trace to determine the
setup that is lacking. Each of the settings is described in detail in the Implementation Guide, along with
navigation to those settings.
To enable Ebiz Tracing for debugging, please follow the instructions in Note 1327445.1.

2.2 About the APPS schema

The Integration requires access to the APPS schema, however, if you do not wish to share the password
for the APPS schema, you will need to refer to document 974949.1 on My Oracle Support. It is possible to
set up secured access to the APPS schema using this note.

2.3 Concurrent Programs

The Publish Item Attributes Updates, Publish Item Balance Updates, and Publish ECO Updates flows are
the three flows included in the Integration that push information from E-Business Suite to Agile. These
flows are executed by concurrent programs in E-Business Suite that you must create in order that they can
be executed.
Concurrent programs can be setup to run at various intervals and options. The Implementation Guide
discusses this setup in great detail. Again, please be sure to follow the instructions in the guide very

-9-
carefully to avoid problems with these three flows in the future.
An additional note is to be sure to review the Expected Behaviors table in the Implementation Guide under
the section related to Concurrent Programs. Be sure that your functional requirements are met by the
scenarios in the table, as this list is exhaustive of what is included with the Integration out-of-the-box. If
there is a scenario not included in the table, you will need to extend and/or customize the Integration to
provide such functionality.

3. Settings related to Middleware (AIA)

After setting up the Participating Applications (Agile and E-Business Suite), there are some steps that need
to be followed to set up the Integration in the AIA layer. These setups have to do with how the data is
transformed from one system to the other, and as such must be set up to account for your specific
environment. The implementation guide is rather exhaustive, as is necessary, for this part of the setup. As
in all setup steps, it is crucial to follow the Implementation Guide to the letter, and take care not to skip any
setup, as this will cause problems once you start to use the Integration.

3.1 Setting up cross reference data

This task will need to be performed if Agile or E-Business Suite, in particular, are in use (live) before the
Integration is installed, configured, and operable. The cross-reference functionality is what enables the
Integration to associate items, parts, and other objects correctly between the two systems. If there is any
correlation that the Integration must maintain between any items that already exist in both systems, you
must perform this task, or there will be data duplication and/or corruption. The PIP logic queries the cross
reference table prior to calling the Ebiz API, and will call the API in insert mode (rather than update mode) if
the item does not exist in the cross-references; thereby creating a new item.
Be advised this task takes some effort, and must be planned carefully. Items that are created through the
Integration (by an ECO release, for example) will be inserted into the table during the integration
automatically. So, this is an up-front setup step, that if done correctly, will not need to be repeated.
The Implementation Guide provides detailed examples, and step-by-step processes for inserting the data
needed into the cross-reference tables, as well as how to retrieve the data required from each participating
application.
Please refer to Note 1317283.1 for additional information and example of how to achieve this.

3.2 Setting up Domain Value Maps

Domain Value Maps are provided as a feature of the SOA Suite and leveraged in AIA to map static data
from one system to another. An example is Units of Measure – A Meter may be defined as “meter” in Agile,
but as “m” in E-Business Suite. Setting up the Units of Measure DVM accordingly will allow the correct unit
of measure to be sent to the destination system.
There are several DVMs that are required to be set up for a non-extended implementation of the
Integration. The Implementation Guide contains a table which lists all the possible DVMs, and highlights
those that are required. Please take time to review the required DVMs to make sure they are set up
correctly for your environment. If they are not set up correctly, the integration flow will fail at one of the
transformations, depending on which DVM is not set up correctly. Again, it is more efficient to take the time
to verify DVM data up front than try to diagnose and correct problems once the system is in use.

-10-
Depending on your functional requirements, DVMs other than what is listed as required may be used.

-11-