24 Establishing Resource Connectivity

This chapter describes how Oracle Application Integration Architecture (AIA) services interact with external resources and discusses inbound and outbound connectivity. The final sections describe specific guidelines for establishing connectivity with Siebel applications and Oracle E-Business Suite.

This chapter includes the following sections:

• Introduction to Resource Connectivity

• Modes of Connectivity

• Siebel Application-Specific Connectivity Guidelines

• Oracle E-Business Suite Application-Specific Connectivity Guidelines

• Design Guidelines

24.1 Introduction to Resource Connectivity

Participating applications drive the business processes. They are either initiators of the business process or play roles in one or more steps in the business process. The interactions of the participating applications with the business process can be either outbound or inbound from the AIA layer perspective.

A business process is a combination of outbound and inbound interactions with various participating applications.

24.1.1 Inbound Connectivity

Inbound means inbound into the AIA layer, as shown in Figure 24-1.

Figure 24-1 illustrates how an inbound interaction to the business process is made by a participating application. Clicking the submit button in the order capture module within a CRM application results in the initiation of the Order Fulfillment business process.

• Services exposed by AIA services are invoked by proxies created by applications. Inbound interactions with AIA might occur due to the notification or broadcast of an event by the participating application or for retrieval of information from external sources. For example - clicking of the 'Get Account Balance' button in a CRM application module could result in invocation of an AIA service by sending a SOAP message over HTTP.

• Applications push messages to JMS queues and topics. JMS servers trigger registered JMS adapter agents and JMS adapter agents trigger AIA services. For example, creation of a customer or submission of an order within CRM modules could trigger the broadcast of these events to AIA in the form of messages to JMS queues and topics.

Figure 24-1 Example of Inbound Connectivity

24.1.2 Outbound Connectivity

Outbound means outbound from the AIA layer, as shown in Figure 24-2.

• AIA services invoke services exposed by applications. AIA services could invoke the application services or the external services to retrieve additional information, to send business events, or to request a task be done. An example is the creation of a customer in billing application when an order is created in the CRM module or an order is submitted for an existing customer in CRM module, but that customer profile is not available in the billing application. Most manufacturing systems publish an event when an item is added however these events contain minimal information about the item. The AIA service consuming the event must invoke an application service to get complete information about the item.

• AIA services interact with applications using JCA adapters and push messages to JMS queues/topics. JMS servers trigger JMS adapter agents registered by applications.

Figure 24-2 illustrates how an outbound interaction is made by the business process. A step within that business process could result in invocation of CRM Order Capture application to send the order status updates.

Figure 24-2 Example of Outbound Connectivity

24.2 Modes of Connectivity

Participating applications use different types of mechanisms for inbound and outbound interactions.

The following sections discuss guidelines and recommendations for participating applications to interact with the AIA architecture.

This section includes the following topics:

• Section 24.2.1, "Web Services with SOAP/HTTP"

• Section 24.2.2, "When to Use Web Services with SOAP/HTTP"

• Section 24.2.3, "Session Management for Web Services with SOAP/HTTP"

• Section 24.2.4, "Error Handling for Web Services with SOAP/HTTP"

• Section 24.2.5, "Security for Web Services with SOAP/HTTP"

• Section 24.2.6, "Message Propagation Using Queues or Topics"

• Section 24.2.7, "Ensuring Guaranteed Message Delivery"

• Section 24.2.8, "When to Use JCA Adapters"

Note:

The contents of this section are general guidelines and recommendations only. Programming methodologies for AIA services can vary based on a participating application's capabilities and currently, some participating applications may not have the capabilities discussed in this section. Refer to the relevant application-specific guides for the facilities provided.

24.2.1 Web Services with SOAP/HTTP

For inbound interaction, the participating application invokes the Application Business Connector Services (ABCS) provided by AIA as Web services. The participating application uses the ABCS WSDL for invoking the ABCS Web services. The ABCS WSDLs are consumed by the participating application to create stubs or proxies. These are internally invoked in the participating application leading to the invocation of the ABCS.

AIA recommends that participating applications leverage Web services transport, as shown in Figure 24-3, for invoking AIA services only to fetch information residing in external systems. For example, querying the account balance details of a customer from billing application using CRM application by a CSR or a self-service application screen.

Figure 24-3 Illustration of Using Web Services with SOAP/ HTTP

In other types of interactions, like create customer, submit order, and so on, AIA recommends that you use either JCA or JMS transports to ensure the interaction is reliable and transactional. If the participating application does not have the capability to use either JMS or JCA transports to publish events to the AIA layer, then you can use the Web services transport, which can help in publishing the events to a queue in the AIA layer for further processing.

Since the ABCS is developed using the schemas from the participating applications, the outbound message format and the ABCS message format are the same.

Inbound Interaction

Inbound messages should have the following attributes:

• Message ID

  The Message ID is the unique identifier for a message generated by the application and stamped on the message. For example, a customer ID or an order ID would be unique in the payload.

• Message payload name

  The name of the business object should be passed.

• Participating application instance

  A unique identifier for the application instance is needed to set the cross reference for the entity IDs, so this is also expected in the payload.

• Event session locale

  The locale information from the client session provides context to the request being made by the application. This helps in ensuring the response is in the same locale context. The locale specific headers should be negotiated with the application teams to decide upon the ABM header attributes. Setting and retrieving the locale specific information is a factor in the ABCS implementation during the request and response transformation steps done on ABM.

Outbound Interaction

For outbound interactions, the ABCS invokes the participating application APIs exposed as Web services. The WSDLs of the participating application Web services are consumed by the ABCS.

24.2.2 When to Use Web Services with SOAP/HTTP

You can leverage Web services with SOAP/HTTP to fetch information from the applications and provide it to the requesters. They are useful when the requirement for interaction reliability is low and operations are limited to querying the information stores.

The message format is XML (Extensible Markup Language).

This mode of connectivity is used in AIA for:

• Request-response

• Request only

24.2.2.1 Request-Response

The SOAP client uses an HTTP GET method to request a representation of a specified resource. The SOAP server triggers the executable and responds back with the output. This is an idempotent action, meaning that multiple identical requests should have the same effect as a single request.

For example, a Customer Sales Representative queries the Customer Master Data Management system for existence of a customer record before creating a new customer in the system.

24.2.2.2 Request Only

The SOAP client uses an HTTP POST to submit data to be processed (for example, from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both. This is a non-idempotent action; therefore sending an identical POST request multiple times may further affect state or cause further side effects.

For example, a Customer submits an order for processing from a Composite Application UI.

24.2.2.3 Advantages of Using Web Services with SOAP/HTTP

Web services with SOAP/HTTP are:

• Platform independent

• Language independent

24.2.2.4 Disadvantages of Using Web Services with SOAP/HTTP

XML format of message processing is slower; therefore, messages must be smaller or must leverage compression techniques.

Inherently, HTTP is stateless (retains no data between invocations); therefore, it needs an explicit login for every call, leading to performance overhead.

The notion of atomic transactions with state management is not supported; workarounds are session state management, where a connection can be reused for multiple requests as discussed in Section 24.2.3, "Session Management for Web Services with SOAP/HTTP."

24.2.2.5 Important Considerations for Using Web Services with SOAP/HTTP

AIA requires that the developed and deployed Web services conform to published WS-I profiles to foster interoperability.

• Leverage WS-Security to secure message exchanges using XML Encryption and XML Signature in SOAP; alternative is using secure HTTP (HTTPS).

• Leverage WS-Addressing to insert address in the SOAP header.

• Leverage WS-ReliableMessaging to reliably deliver messages between distributed applications in the presence of software component, system, or network failures.

24.2.3 Session Management for Web Services with SOAP/HTTP

To overcome the disadvantage of HTTP being stateless and unable to support atomic transactions, session management is needed. This section includes the following topics:

• Section 24.2.3.1, "Session Types"

• Section 24.2.3.2, "SessionToken"

• Section 24.2.3.3, "Session Pool Manager"

24.2.3.1 Session Types

The three types of sessions are:

• None

  A new session is opened for each request and then closed after a response is sent out.

• Stateless

  A new session is opened for an initial request, and the session remains open for subsequent requests. Re-login occurs automatically (transparent to the user) if the session is closed. UsernameToken and PasswordText must be included as SOAP headers in the initial request to open a stateless session.

• Stateful

  A new session is opened for an initial request, and the session remains open for subsequent requests. Re-login does not occur automatically if the session is closed. UsernameToken and PasswordText must be included as SOAP headers in the initial request to open a stateful session.

For Stateless or Stateful modes, Web services are expected to return a SessionToken in the SOAP: HEADER. This depends on the application implementation.

24.2.3.2 SessionToken

A SessionToken is the encryption of the Session ID, UserToken, plus PasswordText.

For each Stateless or Stateful call, an updated SessionToken is returned. This is as a safety measure against replay attacks.

The process of updating the SessionToken does not close the session. Therefore, for the next call with the updated session token there is no re-login. The session remains open. The Session is closed when a call is posted with a Session Type set to None or a timeout occurs. After a second call you have two Session Tokens: the one returned on first call and the updated one from the second call. At this point either of these SessionTokens can be sent for a third call (which returns a third SessionToken). Posting a call with Session Type set to None terminates the Session ID, so all these Session Tokens become invalid.

URL and SOAP Header for the Siebel Application Examples

Example 24-1, Example 24-2, and Example 24-3 provide the URL and SOAP header for the Siebel application examples.

Example 24-1 URL for Calling the Siebel Application and Passing Login Information in the SOAP Header

http://sdcp1952i028.corp.siebel.com/eai_enu/start.swe?SWEExtSource=
SecureWebService&SWEExtCmd=Execute&WSSOAP=1

The SOAP header looks like this:

Example 24-2 SOAP Header

<soapenv:Header>
<UsernameToken xmlns="http://siebel.com/webservices">rreddy</UsernameToken>
<PasswordText xmlns="http://siebel.com/webservices">rreddy</PasswordText>
<SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType></soapenv:Header>

The response looks like this:

Example 24-3 Response to SOAP Header

<SOAP-ENV:Header>
<siebel-header:SessionToken 
xmlns:siebel-header="http://siebel.com/webservices">0f2cnvf0Ii5qsp-zk-
SEyjl2p0JD-QdYLt1LYvARXQMZfAL9YL.THekJHI1cVjZbBGQckQN.
cIfOGPKWKwUd6E0D4LD.VS.CKWsXw...</siebel-header:SessionToken>
</SOAP-ENV:Header>

24.2.3.3 Session Pool Manager

For business integration flows that require a high number of concurrent request-response calls to applications, AIA recommends that you send and receive session token information rather than sending user credentials on each call.

• The Session Pool Manager is a service that manages a pool of session tokens to be reused for subsequent requests.

• The sessions are persisted either in memory or in a database.

• The login credentials and URLs are configured by an administrator in the Session Pool Manager.

The implementation of the Session Pool Manager is application-specific, taking into consideration the Web service framework implementations.

24.2.4 Error Handling for Web Services with SOAP/HTTP

This section discusses error handling for Web services with SOAP/HTTP:

• Section 24.2.4.1, "For Inbound Connectivity"

• Section 24.2.4.2, "For Outbound Connectivity"

• Section 24.2.4.3, "Request-Response and Request-Only System Errors"

• Section 24.2.4.4, "Request-Response Business Errors"

24.2.4.1 For Inbound Connectivity

Participating applications should have the capability to consume WSDLs with fault messages defined.

The WSDLs provided to participating applications are generated for the coarse-grained request-response services created using BPEL (ABCS). The input and output payloads for these services are schemas provided by the participating applications. Fault schemas provided by applications aid in incorporating them in the definitions of the services (WSDLs).

24.2.4.2 For Outbound Connectivity

The WSDLs of the participating application services are consumed by the AIA services. The error handling depends on the message exchange pattern.

24.2.4.3 Request-Response and Request-Only System Errors

• Call from the participating application not successful

  The AIA layer returns HTTP 4xx Client Error and the participating applications must have the mechanism to resubmit manually or automatically.

  Example: FMW is down and AIA service is not accessible.

• Call from the participating application successful but system resource not accessible

  The AIA layer returns 5xx Server Error and the participating applications must have the mechanism to resubmit manually or automatically.

  Example: From the AIA service execution, the cross-reference database is not accessible.

24.2.4.4 Request-Response Business Errors

• WSDL of the participation application service has named fault

  In this case, the WSDL has a named fault with a specified fault message format. The AIA service, on encountering a business error, puts the error information in the fault message and reply back to the calling service. The participating application takes action accordingly.

  Example: An order with invalid options is pushed by CRM application to ERP application and fails validation in the ERP application. Upon receiving the fault, the AIA service constructs an appropriate error message, transforms it to the fault schema of the CRM application, and sends it back as a named fault.

• WSDL of the participation application service has no named fault

  This case has two possibilities:

  • WSDL response message has component and elements for specifying error

    In this case, the AIA service, on encountering a business error, would put the error information in the response message fault component and elements and reply back to the calling service. The participating application takes action accordingly.

  • WSDL specifies no valid way for receiving fault information

    Two options:

    • Send back the fault as a SOAP fault if the FMW component used for the AIA service supports it.

    • Model the interaction as Request-Only and make provisions for a separate participating application Web service to receive the result.

24.2.5 Security for Web Services with SOAP/HTTP

The participating applications should receive authentication information in WS Security username token profile format. They should be able to design and decrypt the request and sign and encrypt the response. They should preferably receive authorization information in xacml format inside SOAP headers.

24.2.6 Message Propagation Using Queues or Topics

Participating applications can enqueue messages to queues (JMS, AQ, MQ, MSMQ, and so on) for inbound interactions. The participating applications construct messages for various events raised and enqueue the messages into named queues. The AIA services subscribing to these queues are triggered. These are asynchronous in nature. Publishing of a message into a queue should be part of the same transaction that occurred within the application.

Participating applications also can dequeue messages from queues (JMS, AQ, MQ, MSMQ, and so on) for outbound interactions. AIA services construct messages for various events raised and enqueue the messages into named queues. The participating applications subscribing to these queues de-queue and process the messages. These are asynchronous in nature. Publishing of a message into a queue should be part of same transaction that occurred within the AIA service.

The queuing mechanisms are asynchronous in nature. They consist of one-way calls.

24.2.6.1 Event Notification Without Payloads

For event notifications without payloads, the ABCS adapter that is subscribing to or polling the events pulls out the message from the participating application. A series of events are triggered, but there is no guarantee that the snapshot of the updated entity pulled from the participating application corresponds to the event. AIA suggests that events be user-triggered so that the data integrity is not compromised. Message sequencing is not possible in this case.

To ensure the guaranteed delivery of the event notifications, these notifications should be able to receive an acknowledgment from AIA layer and the participating applications should be able to resend or do proper error handling of these event notifications. All these events should be preserved and aggregated based on the ID or timestamp in the AIA layer and further processing should be done at regular intervals to ensure the data integrity.

24.2.6.2 Events Leading to Message Queuing

When messages are queued because of events raised, the messages capture the snapshot of the entity state. If there are a series of operations on an entity in close succession, a series of messages for the same entity with different states arrive at the queue. Due to network latencies or errors in messages being processed, the ordering of messages in such a situation cannot be guaranteed.

AIA services can process the messages in the correct sequence if some requirements are fulfilled.

• Requirements for sequencing of messages

  For the messages to be sequenced, there should be a defined set of messages that must be sequenced. In addition, every message should be identifiable as a part of a sequence.

• Identifier for the set of messages to be sequenced

  A named parameter like a Group ID is defined. All the messages having a common value are part of the same group or set of messages to be sequenced.

• Identifier for the message to be sequenced

  A named parameter like a Sequence ID is defined. The value for this parameter can be a number or date-time. This value determines the position of each message in a sequence.

24.2.6.3 When to Use Message Propagation Using Queues or Topics

Meeting either of these two criteria leads to using message propagation using queues/topics:

• Must break processes into atomic transactions

• Event triggering system cannot wait till the message is processed

24.2.6.4 Types of Queues

The two types are:

• Queues

• Topics

Queues

A Queue is a persistent storing mechanism designed for holding elements before processing.

Points to note:

• Queues are point-to-point.

• Only one consumer gets the message.

• The producer does not have to be running at the time the consumer consumes the message, nor does the consumer have to be running at the time the message is sent.

• Every message successfully processed is acknowledged by the consumer.

Considerations for Using Queues

When using queues, consider the following:

• AIA recommends that you use WLSJMS Queues for inbound and outbound interactions with participating applications.

• If the application is not compatible or does not have the ability to send or receive messages to and from AIA using WLSJMS, then any other supporting messaging should be used. For example, AQJMS or TIBCOJMS, and the required foreign JMS server setup should be done on native WLSJMS to interact with the applications.

• AIA recommends that you configure a file-based persistent store for WLSJMS queues. If you must use the database persistence for bulk messages, or for policy or business requirements, configure database persistence. Configuring the persistent store as file-based or database-based can be decided during deployment time.

• The Foundation Pack AIA installation driver automatically creates the error queues for each queue.

• To generate the error queue name, the Foundation Pack deployment plan generator scripts use the resource name from annotations to get the queue or topic name and then append "_ErrorQ" as suffix. For example, for the "AIASalesOrderQueue", the generated error queue would be "AIASalesOrderQueue_ErrorQ".

• The Foundation Pack AIA installation driver uses the deployment plans to ensure creating, configuring, or assigning the generated error queue name for each JMS queue that it creates on WLS.

• Foundation Pack creates one generic "non-XA" connection factory for connecting to all the error queues from the error resubmission utility. The name of the generic connection factory is "AIAErrorQueueConnectionFactory".

• The generic error connection factory is created during the Foundation Pack install. The error queues generation happens during the Pre-Built Integration installation based on the annotations.

• For the integration flow milestones, AIA recommends that you use the WLSJMS Queues with file-based persistent store.

Topics

A topic is a persistent storing mechanism designed for holding elements before processing. For processing, messages are delivered to multiple subscribers.

Points to note:

• Multiple consumers can get the message.

• A timing dependency exists between publishers and subscribers. The publisher has to create a subscription in order for clients to be able to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected are redistributed whenever it reconnects.

• For the publish-subscribe model, AIA recommends that you use WLSJMS topics.

24.2.7 Ensuring Guaranteed Message Delivery

Guaranteed message delivery means a message initiated from the sender system is persisted until it is successfully delivered to and acknowledged by the receiver, if acknowledgment is expected. This delivery method ensures that messages are not lost under any circumstance.

The sender and receiver are not necessarily the participating applications. Rather, they are logical milestones in a business process. Multiple milestones may exist, as illustrated in Figure 24-4 and Figure 24-5.

Figure 24-4 Example of Multiple Milestones in a Business Process (1 of 2)

Figure 24-5 Example of Multiple Milestones in a Business Process (2 of 2)

• Temporary unavailability of any hardware or software service does not result in a lost message or a delivery failure, ensuring that the message is delivered.

• The Error Handling framework provides a way for the message to be persisted until the hardware or software service becomes available for retry, and to reprocess the message after correction or initiate a new message after discarding the existing message.

• Message delivery is ensured by treating the message processing between any two integration milestones as a unit of work and binding it in a single global transaction.

24.2.7.1 When to Use Transaction Boundaries

Use transaction boundaries when:

• Different components are involved in the processing of messages. They can be JMS consumer adapter services, BPEL processes, Mediator services, cross reference calls, and JMS Producer adapter services.

• Global transactions are enabled across all the components, and the transaction boundary is established between the integration milestones, which ensures that the messages are persisted in the source milestone until delivered to the target milestone.

24.2.8 When to Use JCA Adapters

Use JCA adapters when the application has the implementation of an adapter based on the Oracle FMW-supported JCA specifications. These adapters can be purchased from Oracle certified third-party vendors if they support the required JCA specifications.

JCA adapters should be transactions enabled. To ensure guaranteed delivery and get the participating application to enlist in the XA transactions, the JCA adapter and the application should build the capabilities which are required for building the AIA composite business processes.

The JCA adapter can be a queue or topic adapter for AQ or JMS. Also, the JCA adapter can expose the business object APIs of a particular application. The granularity of the API demands chatty conversations with the participating application. AIA recommends that an application should expose the coarse-grained API (though it might call multiple fine-grained APIs in the application's implementation). This exposure avoids chatty conversations and improves the overall performance for a business transaction.

For more information about JMS Adapters, see Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.

24.3 Siebel Application-Specific Connectivity Guidelines

The following sections discuss how to establish inbound and outbound connectivity with Siebel applications:

• Section 24.3.1, "Inbound: Siebel Application Interaction with AIA Services"

• Section 24.3.2, "Web Services with SOAP/HTTP"

• Section 24.3.3, "Creating JMS Consumers to Consume Siebel Messages from JMS Queues/Topics"

• Section 24.3.4, "Outbound - Siebel Application Interaction with AIA Services"

• Section 24.3.5, "Web Services with SOAP/HTTP"

24.3.1 Inbound: Siebel Application Interaction with AIA Services

Siebel applications present requests to AIA services when the Siebel application is the driving application initiating business processes, business activities, and tasks. The Siebel application can either invoke AIA services exposed as Web services or push messages directly to JMS queues triggering AIA JMS consumers.

The format of the requesting messages can either be native to Siebel or conform to the AIA Enterprise Business Objects (EBO).

If the format is native, Siebel Tools generate schemas for the Siebel Integration Objects and provide for creating AIA services.

For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.

24.3.2 Web Services with SOAP/HTTP

Siebel Tools (Siebel IDE) needs AIA service WSDLs. Siebel Tools introspects the WSDLs and generates proxies to invoke AIA services at runtime. Siebel Tools generates schemas for the Siebel Integration Objects, and these are used to develop AIA requester ABCS.

Perform the following tasks as part of the AIA Project Management Lifecycle for the Service Conception and Definition phase and the Service Design and Construction phase.

For more information about these AIA lifecycle phases, see Section 2.2.3, "Introduction to the Business Process Decomposition and Service Conception Phase" and Section 2.2.4, "Introduction to the Service Design and Construction Phase."

Tasks for Solution Architects in the Service Conception and Definition phase:

1. Identify the requester ABCS for the Siebel application and add them to the AIA project definition.

2. For new services, work with business analysts to capture the requirements in detail.

3. For existing services, work with business analysts to capture details of changes to be carried out.

4. Work with developers and drive the design of the services.

5. Finalize the format of the message.

6. Finalize the WSDL of the AIA requester ABCS.

7. Ensure the metadata of the service is captured in the Oracle Enterprise Repository.

8. Add the service to the deployment plan of the AIA project definition.

Tasks for Developers in the Service Design and Construction phase:

1. Analyze the Siebel requester Application Business Service definition provided by the Solution Architect.

2. Work with Siebel Application development and discuss the possible design.

3. Finalize the content of the message from Siebel.

4. Get the schema of the message from Siebel and ensure the following:

   1. TargetNameSpace - If higher than version 0, must have suffix V<N> where V is abbreviation for version and N is the version number. If there is no version number, it is considered to be version 0. Example 24-4 provides an example of version 1.

      Example 24-4 Example of a Version 1 TargetNameSpace

      <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema targetNamespace=" 
      http://siebel.com/asi/V1" xmlns:xsd=http://www.siebel.com/xml/SWICustomerPartyIO
      

   2. Custom Attributes - Attributes in Example 24-5 are required:

      Example 24-5 Required Custom Attributes

      <xsd:attribute name="Language" type="xsd:string"/>
      <xsd:attribute name="Locale" type="xsd:string"/>
      <xsd:attribute name="MessageId" type="xsd:string"/>
      <xsd:attribute name="EnterpriseServerName" type="xsd:string"/>
      

      A sample of custom attributes is provided in Example 24-6.

      Example 24-6 Sample Custom Attributes

      <xsd:complexType name="ListOfSwicustomerpartyio">
      <xsd:sequence> <xsd:element name="Contact" type="xsdLocal:Contact" minOccurs=
      "0" maxOccurs="unbounded"/></xsd:sequence>
         <xsd:attribute name="Language" type="xsd:string"/>
        <xsd:attribute name="Locale" type="xsd:string"/>
        <xsd:attribute name="MessageId" type="xsd:string"/>
               <xsd:attribute name="EnterpriseServerName" type="xsd:string"/
      </xsd:complexType>
      

5. Construct a requester ABCS using the AIA Service Constructor.

6. Provide the WSDL from this service to the Siebel Application development team.

24.3.3 Creating JMS Consumers to Consume Siebel Messages from JMS Queues/Topics

Siebel Tools generates schemas for the Siebel Integration Objects, and these are used to develop AIA requester ABCS.

Perform the following tasks as part of the AIA Project Management Lifecycle, during the Service Conception and Definition phase and the Service Design and Construction phase.

For more information about these AIA lifecycle phases, see Section 2.2.3, "Introduction to the Business Process Decomposition and Service Conception Phase" and Section 2.2.4, "Introduction to the Service Design and Construction Phase."

Tasks for Solution Architects in the Service Conception and Definition phase:

1. Analyze the message to be pushed by the Siebel application.

   Since the Siebel application pushes the message using the Siebel Web Service framework, it is wrapped in the <SiebelMessage/> envelope. This must be stripped off in the JMS consumer.

2. Create the definition of JMS consumer solution component in the AIA Lifecycle Workbench and mark it as of suitable asset type.

Tasks for Developers in Service Design and Outline Construction phase:

1. Create a JMS Consumer Service Composite to be triggered by the message in the JMS queue and invoke the above ABCS.

2. Identify the name of the Queue.

3. Use the SOA Mediator component to create the adapter composite.

4. Annotate the composite.xml.

   For more information, see Section 13.6, "How to Annotate the Transport Adapter Composite."

5. Harvest to Oracle Enterprise Repository.

   For more information, see Chapter 5, "Harvesting Oracle AIA Content."

24.3.4 Outbound - Siebel Application Interaction with AIA Services

Siebel applications accept requests from AIA services when an action or event in the Siebel application is part of business processes, business activities, or tasks. AIA services can either invoke the Siebel application exposed Web services or push messages directly to JMS queues triggering Siebel JMS consumers.

The format of the accepting messages can either be native to Siebel or conform to the AIA Enterprise Business Objects (EBO). If the format is native, Siebel Tools generates WSDLs for the Siebel Web services and provides for consumption by AIA services.

24.3.5 Web Services with SOAP/HTTP

Siebel Tools (Siebel IDE) generates Web Service WSDLs that are used to develop AIA Provider ABCS.

Perform the following tasks as part of the AIA Project Management Lifecycle for the Service Design and Construction phase:

Tasks for Developers in Service Design and Construction phase:

1. Analyze the Siebel Provider ABCS definition provided by Solution Architect.

2. Work with Siebel Application development and discuss the possible design of the needed Web services.

3. Finalize the content of the message to Siebel.

4. Get the WSDL of the Web Service and the accompanying schema from Siebel application team.

5. Put them in relevant folders in the MDS under AIAMetaData/ApplicationObjectLibrary.

6. Complete development of the Siebel provider ABCS.

24.3.5.1 Session Management

Siebel Web Service Framework supports Non and Stateless type sessions. To have a different session type, you must add SessionType in the SOAP Header.

Siebel Authentication and Session Management SOAP headers can be used to send and receive user credentials and session information. Username and password can be sent for login that invokes one of the following sessions:

• One that closes after the outbound response is sent.

• One that remains open after the response is sent.

For more information, see:

• Integration Platform Technologies: Siebel Enterprise Application Integration, "Web Services," Examples of Invoking Web Services

• Integration Platform Technologies: Siebel Enterprise Application Integration, "Web Services," Mapping the xsd:any Tag in the XML Schema Wizard

• Oracle Application Integration Architecture Pre-Built Integrations: Utilities Guide, "Session Pool Manager"

Use the Stateless type for session management. Stateless keeps the Siebel session persistent.

Siebel Web Service Framework Stateless Session is independent of the Web server.

Every response has a new SessionToken that must be used in the next request.

24.4 Oracle E-Business Suite Application-Specific Connectivity Guidelines

The following sections discuss how you can establish inbound and outbound connectivity with Oracle E-Business Suite (E-Business Suite) applications:

• Section 24.4.1, "Inbound: E-Business Suite Application Interaction with AIA Services"

• Section 24.4.2, "Concurrent Program Executable"

• Section 24.4.3, "Business Event Subscription (JCA Connectivity Using OAPPS Adapter)"

• Section 24.4.4, "Outbound: Oracle E-Business Suite Application Interaction with AIA Services"

24.4.1 Inbound: E-Business Suite Application Interaction with AIA Services

The E-Business Suite application sends requests to AIA services when E-Business Suite is a driving application initiating business processes, business activities, or tasks. E-Business Suite can either invoke AIA services exposed as Web services with the help of concurrent program executable or raise business events to the AIA layer through JCA Adapter (Oracle Apps Adapter). JCA Adapter should be configured to subscribe for a particular business event.

The format of the requesting messages can either be native to E-Business Suite Application Business Message (ABM) or conform to the AIA Enterprise Business Message (EBM).

24.4.2 Concurrent Program Executable

E-Business Suite needs AIA service WSDLs. E-Business Suite should generate proxies and use them in the concurrent program executable to invoke AIA Services at runtime. E-Business Suite should generate the schemas (ABMs) which are used to define the contracts (WSDLs) between AIA and E-Business Suite and to develop AIA requester ABCS.

Perform the following tasks as part of the AIA Project Management Lifecycle for the Service Conception and Definition phase and the Service Design and Construction phase:

Tasks for Solution Architects in Service Conception and Definition Phase:

1. Identify the requester ABCS for E-Business Suite and add them to the AIA project definition.

2. For new ABCS, work with business analysts to capture the requirements in detail.

3. For existing ABCS, work with business analysts to capture details of extensions to be carried out.

4. Work with developers and drive the design of the ABCS.

5. Choose the right connectivity based on the E-Business Suite capability to communicate the required ABM to AIA based on the business requirements: Select Concurrent Program Executable or Business Event Subscription.

6. Finalize the format of the message (E-Business Suite ABM).

7. Finalize the contract between E-Business Suite and AIA, that is, define the WSDL of the AIA requester ABCS.

8. Define and finalize the error or fault handling message format between E-Business Suite and AIA.

9. Define the error handling mechanism and the style of AIA errors to be displayed and logged for the E-Business Suite application user.

10. Finalize on the MEP between E-Business Suite and AIA.

Follow Best Practices and Design Asynchronous Patterns to Avoid Long Running Transactions

1. Finalize on the type of acknowledgment for asynchronous operations.

2. Ensure the metadata of the service is captured in the Oracle Enterprise Repository.

3. Add the service to the deployment plan of the AIA project definition.

Tasks for Developers in Service Design and Construction phase:

1. Analyze the E-Business Suite requester ABS definition provided by solution architect.

2. Work with E-Business Suite development and discuss the possible design.

3. Finalize the content of the message from E-Business Suite.

4. Get the schema of the message from E-Business Suite and ensure the following:

   TargetNameSpace - If higher than version 0, must have suffix V<N> where V is abbreviation for version and N is the version number. If there is no version number, it is considered to be version 0. Example 24-7 provides an example of version 0.

   Example 24-7 Example of a Version 0 TargetNameSpace

   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   targetNamespace="http://xmlns.oracle.com/ebiz/CurrencyExchange" 
   xmlns:db="http://xmlns.oracle.com/ebiz/CurrencyExchange" 
   elementFormDefault="qualified">
   <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema 
   targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayable
   InvoiceListEbizDBAdapterV1" 
   xmlns=http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayableInvoiceList
   EbizDBAdapterV1
   

5. Construct a requester ABCS using AIA Service Constructor.

   Provide the WSDL from this service to the E-Business Suite development team.

24.4.3 Business Event Subscription (JCA Connectivity Using OAPPS Adapter)

Subscription for Enterprise Business Service (EBS) Workflow business events can be achieved by having the Business Event Adapter (OAPPS adapter) available in Oracle JDeveloper as a plug-in, which can be used to invoke any service to raise a business event in E-Business Suite. A WF_BPEL_Q queue gets created as a subscription to the event and the adapter reads the events from the WF_BPEL_Q as and when a message arrives in the queue it triggers the adapter service.

E-Business Suite should generate the schemas (ABMs), which are used to define the contracts (WSDLs) between AIA and E-Business Suite and to develop AIA requester ABCS.

For some business objects, the ABMs generated have only event information. In such situations, the business object ID is extracted from the event information published and E-Business Suite is queried to get the whole object.

Perform the following tasks as part of the AIA Project Management Lifecycle for the Service Conception and Definition phase and the Service Design and Construction phase:

Tasks for Solution Architects in Service Conception and Definition Phase:

1. Identify the requester ABCS for E-Business Suite and add them to the AIA project definition.

2. For new ABCS, work with business analysts to capture the requirements in detail.

3. For existing ABCS, work with business analysts to capture details of extensions to be carried out.

4. Work with developers and drive the design of the ABCS.

   1. Choose the best connectivity based on the E-Business Suite capability to communicate the required ABM to AIA based on the business requirements: Select Concurrent Program Executable or Business Event Subscription.

   2. Finalize the format of the message (ABM).

   3. Finalize the contract between E-Business Suite and AIA. Define the WSDL of the AIA requester ABCS.

   4. Define and finalize the error or fault handling message format between E-Business Suite and AIA.

   5. Define the error handling mechanism and the style of AIA errors to be displayed/logged/alert mechanism to E-Business Suite user.

   6. Finalize on the MEP between E-Business Suite and AIA.

   7. Follow the best practices and design asynchronous patterns to avoid long running transactions.

   8. Finalize on the type of acknowledgment for asynchronous operations.

5. Ensure the metadata of the service is captured in the Oracle Enterprise Repository.

6. Add the service to the deployment plan of the AIA project definition.

Tasks for Developers in Service Design and Construction Phase:

1. Analyze the E-Business Suite requester ABCS definition provided by the solution architect.

2. Work with E-Business Suite development and discuss the possible design.

3. Finalize the content of the message from E-Business Suite.

4. Get the schema of the message from E-Business Suite and ensure the following:

   TargetNameSpace - If higher than version 0, must have suffix V<N> where V is abbreviation for version and N is the version number. If there is no version number, it is considered to be version 0. Example 24-8 provides an example of version 1:

   Example 24-8 Example of a Version 1 TargetNameSpace

   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   targetNamespace="http://xmlns.oracle.com/ebiz/CurrencyExchange" 
   xmlns:db="http://xmlns.oracle.com/ebiz/CurrencyExchange" 
   elementFormDefault="qualified">
   <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema 
   targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayable
   InvoiceListEbizDBAdapterV1" 
   xmlns=http://xmlns.oracle.com/pcbpel/adapter/db/top/CreatePayableInvoiceList
   EbizDBAdapterV1
   

5. Construct a requester ABCS using AIA Service Constructor.

6. Provide the WSDL from this service to the E-Business Suite development team.

7. Create an E-Business Suite Adapter Service Composite to be triggered by the business event in E-Business Suite and invoke the JMS producer service.

8. Identify the connection factory name and the JNDI reference.

9. Identify the business event to be subscribed.

10. Identify the schema to be confirmed for the incoming message or business event.

11. Use the SOA Mediator component to create the adapter composite.

12. Identify the target queue name, connection factory name, and the JNDI reference.

13. Annotate the composite.xml.

    For more information, see Section 13.6, "How to Annotate the Transport Adapter Composite."

14. Harvest to Oracle Enterprise Repository.

    For more information, see Chapter 5, "Harvesting Oracle AIA Content."

24.4.4 Outbound: Oracle E-Business Suite Application Interaction with AIA Services

The E-Business Suite application accepts requests from AIA services when AIA service, composite business process, or Enterprise Business Flow is initiating a request to E-Business Suite. AIA can invoke E-Business Suite in one of the following ways:

• A PL/SQL procedure or function can be invoked using database or Oracle Apps Adapter. These adapters are available as plug-ins in Oracle JDeveloper. Oracle Apps Adapter is a wrapper over DB Adapter where it sets the FND Apps context before invoking the PL/SQL procedure/function.

• Invoke a JAVA based Web Service exposed using Business Service Objects (BSO).In Oracle- E-Business Suite, there is no direct way to expose a JAVA API as a service hosted on Oracle- E-Business Suite application server. However, it is possible to expose Oracle Application Development Framework Application Modules as services using the BSO feature provided by Oracle Applications tech-stack. These services come up in Integration Repository (IRep) and can be invoked as service from remote applications.

  For more information about BSO, see Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

• Loading data into Interface tables and calling a concurrent program to process the data. AIA can populate data into EBS interface tables using DB/Apps adapter and then call a concurrent program or post-processing APIs using DB/Apps adapter to process this data.

• A DB adapter can be made to poll from Oracle- E-Business Suite tables to initiate integration services thereof. A DB adapter must be configured with the help of the JDeveloper wizard by selecting the appropriate BusinessEvents or API. JDeveloper creates .sql files which must be executed on the Ebiz database to create subscriptions for listening to the events.

The format of the outgoing messages should be in the native format to E-Business Application Business Message (ABM).

The development and design tasks are similar to the inbound connectivity as discussed above. The architect or designer should identify how the business functionality is exposed in E-Business and identify the available path from the four ways listed above to connect to E-Business. Based on the general guidelines for each transport, the architect or designer should decide which transport would be suitable for the given business requirement.

24.5 Design Guidelines

AIA services are leveraged to implement tasks, business activities, and business processes.

These common design and development guidelines are applicable to all interactions using different resources and are applicable to both inbound and outbound interactions.

The following points should be considered depending on the type of pattern:

• Push event notifications without message

  • Event notification with guaranteed delivery requirement - leverage JCA Adapter, if available, otherwise use queues.

  • Event notification for non-critical situations - use Web services.

• Push events with message

  • Request event soliciting information and waiting for information - leverage JCA Adapter, if available, or use Web services.

  • Request event propagating state change - leverage JCA Adapter, if available, otherwise use queues.

  For more information, see Chapter 28, "Working with AIA Design Patterns."