Enterprise Administration > Implementing Windchill ESI > Implementing Windchill ESI in an ORACLE Applications Environment > Understanding Windchill ESI Architecture > Supporting Multiple Oracle Applications Instances
  
Supporting Multiple Oracle Applications Instances
Windchill ESI supports the publishing of data to distribution targets belonging to multiple ERP instances. By generating one Windchill ESI response message per ERP instance, the published data is routed by the EAI software components to the relevant distribution targets.
Windchill ESI services places response messages on multiple TIBCO EMS queues. Each response message caters to an ERP instance. As well, multiple EAR applications deployed in TIBCO middleware use these messages for publishing data to the relevant distribution targets. Therefore, each application subscribes to a unique EMS queue, and is configured to connect to one ERP instance. The following diagram provides an overview of the desired objective:
Windchill ESI Services and TIBCO EMS Queues
As indicated in the above diagram, the name of a given EMS queue is composed of two parts. The first part is determined by the value of the Windchill ESI preference named Data Response Queue Name. The second part is determined by the specifics of the ERP instance the queue provides for. For example, in Oracle Applications, when publishing to an Oracle Applications instance, this would consist of the DSN (Data Source Name) associated with the given instance. The queue name takes the following form:
<Value of the preference>.<DSN>
The specifics of the ERP instance viz., the DSN in this case, is obtained from the relevant distribution target attribute stored with the ESITarget object in Windchill. Also obtained from the distribution target is the attribute named Task Uniform Resource Identifier, which holds the name of the I*E task that Windchill ESI services invoke for placing a response message on the relevant EMS queue. Out of the box, this attribute has the value "com/ptc/windchill/esi/export/ ExportToJMSQueue.xml", which is a path relative to the <Windchill>/tasks folder.
* 
The Windchill ESI preference Data Response Queue Name is set to the value com.ptc.windchill.esi.DataResponse out of the box. The I*E task in ExportToJMSQueue.xml fetches the relevant queue name by appending the specifics of the ERP instance to this value.
The value input by a user for the field Oracle Mfg. Data Source DSN that appears in the Oracle Mfg. ERP Properties window of the MICU (Middleware Installation and Configuration Utility) should match the value specified for the attribute DSN of the corresponding distribution target object in Windchill. Also, if the Windchill ESI preference Data Response Queue Name has a value other than the default mentioned above, the value for the field Queue name for ESI EMS Data Response of the ESI EMS Queues window should be changed appropriately.
With reference to the architecture diagram, the queue name com.ptc.windchill esi.DataResponse.ORAPTCPROD, uses the default value for the Windchill ESI preference and a value of ORAPTCPROD for DSN.
TIBCO EAR Applications
The MICU allows you to deploy out of the box EAR applications for multiple ERP instances. Each deployment contains a process archive service consisting of business logic executed by the BW engine, and a couple of ADB 6.3 Adapter archive services one of which contains a publication service that publishes log messages to the process archive, while the other has subscription services for various object types and is responsible for establishing a connection to Oracle Applications. The process archive for a deployment subscribes to an EMS queue whose name is based on the TIBCO global variable ESIJMS/DataResponseQueue. This global variable is populated by the MICU using the value for the relevant field entered by the user in the Oracle Mfg. ERP Properties window.
The process archive service is closely tied to the adapter archive service. For example, with reference to the architecture diagram, the process archive service of a given deployed application (for example Oracle_Apps-1) is able to communicate only with the adapter archive service of the same application. This is achieved by using a unique subject name that is passed by the process engine to the adapter. The subject name has the following form:
%%Domain%%.%%Deployment%%.%%ESIOMAdapter/Datasource%%.<<ERP API Service Name>>
* 
In the above name, anything that is enclosed within a pair of "%%" characters is a global variable name and its value will be used while generating the subject name. The meanings of the various elements that make up the subject name are as follows:
Domain is the name of the domain in which the TIBCO project (or repository) resides. This is automatically set by TIBCO BusinessWorks when a project is created or deployed.
Deployment is the name of the project, automatically set by TIBCO BusinessWorks.
ESIOMAdapter/Datasource is a mandatory element in the name and is used by the adapter for creating a connection with the Oracle Applications database using ODBC.
For example, an adapter service configured for creating a part in the ERP system using the deployed application "Oracle_Apps-1" may use the following subject name:
ESIPTCDomain.Oracle_Apps-1.PTC_BL_PROD.Item
The above listed example uses "ESIPTCDomain" for the TIBCO Administrator domain name, "Oracle_Apps-1" for the deployment name, "PTC_BL_PROD" for the global variable ESIOMAdapter/Datasource, and "Item" for the ERP API Service Name.
* 
The deployment name, for example "Oracle_Apps-1”, is unique across a given TIBCO Administrator domain. Also, the value Item indicates that the API service is for processing of items.
Each deployed application requires the following ERP connection parameters:
ESIOMAdapter/DSN
ESIOMAdapter/UserName
ESIOMAdapter/Password