Choose a thread pool size that matches the requirements of your application and tracking level.

If you do not create these pools, threads will be consumed from the default thread pool. For more information about execution thread pools, see "Creating Execute Queues" in Tuning WebLogic Server Applications in WebLogic Server Performance and Tuning.

For more information about this configuration, see Synchronous Clients for Asynchronous Business Processes in "Building Synchronous and Asynchronous Business Processes" in the "Guide to Building Business Processes" in "Building Integration Applications" in the WebLogic Workshop Help. For implementation examples, see the WebLogic Integration Solution Samples.

Message Broker Resources

Any time the Message Broker publishes a message through a Message Broker publish control or event generator, the following actions occur:

• A list of subscribers is retrieved from the in-memory subscription information table.
• For each static subscriber (a subscriber that has a subscription on a start operation) interested in receiving messages listening on a particular channel:
• If the subscription has no filter, it is sent.
• If the subscription has a filter, it is evaluated and if it matches, the message will be sent.

Note: Database tables are never used for static subscribers.

• For each dynamic subscriber (a subscriber that has a subscription on a Message Broker subscriber control) interested in receiving messages listening on a particular channel:
• The subscriber updates the dynamic subscribers table when doing a subscribe operation.
• For each unique filter declared on subscription controls, the XQuery declared on the subscription is used to extract an XML fragment from the to-be-published document or metadata. The XML fragment is then effectively used as a select value into the dynamic subscribers table. The result set from the select is then used as the list of subscribers to publish to for that unique filter.

The Message Broker uses the same JMS asynchronous queue that the process control uses. Once a message is enqueued, it follows the same code path as if it were sent using the process control. For more information about publishing using the Message Broker control, see the following figure.

Figure 1-7 Publishing Using the Message Broker Publish Control




 

Event Generator Resources

WebLogic Integration has a number of native event generators:

• Email
• File
• HTTP
• JMS
• MQSeries
• RDBMS
• Timer

In addition, event generators are used for application integration EIS events. (For additional information regarding event generators for EIS adapters, see Application Integration Capabilities and Clients.)

The JMS Generator

The JMS event generator is packaged as a message-driven bean pool. It can be targeted freely to any number of managed servers in a cluster. It would typically be targeted to either a single managed server when using a physical JMS destination, or to the cluster when using distributed destinations.

The File, Email, and Timer Event Generators

These event generators are "polling" event generators, in that they poll for events to happen. To do this, each event generator is packaged as a message-driven bean pool and configured with a specific JMS queue. Messages are sent from the event generator to its associated queue with a delivery time of poll-interval in the future. The queue is shared between event generators of the same type (file, email, and so on), and a selector is used to share messages in the queue.

How you target a polling event generator depends on how the JMS server owning the associated queue has been targeted, as shown in the following table.

Because the polling event generators would contend with each other during their polls, they are restricted to being active on a single managed server in a cluster. When an event generator is associated with a migratable queue, it is active only on the single server containing the migratable JMS server—even though the polling event generator is targeted to the cluster.

Note: WebLogic Integration supports polling event generators targeted to a single server. However, this configuration is not appropriate for applications that require high availability.

The MQSeries and HTTP Event Generators

The HTTP event generator is a servlet which takes HTTP requests, checks for the content type, and then publishes the messages to Message Broker channels. The MQSeries event generator polls for messages on a WebSphere MQ queue and publishes the messages (MQMD headers as metadata along with the message payload) to Message Broker channels. Content filtering, as well as other handling criteria, are specified in the channel rules for the event generator. Both the HTTP and MQSeries event generators can be targeted to a single managed server or cluster, as described in the Event Generators section of Managing WebLogic Integration Solutions.

The RDBMS Event Generator

The RDBMS event generator polls the database table to check for added, deleted, or updated rows and publishes the results to Message Broker channels. You can also use this event generator to run custom queries on the database table and publish the results to Message Broker channels, as described in the Event Generators section of Managing WebLogic Integration Solutions.

Suspending Event Generators

It is important to note that the suspended status of an event generator is not preserved when the server is restarted. If the event generator is in the suspended state when the server is restarted, the event generator remains suspended and no events are processed. You can restart the event generator by setting it to `running' from the WebLogic Integration Administration Console. For more information, see the Event Generators section of Managing WebLogic Integration Solutions.

Trading Partner Integration Resources

Trading Partner Integration (TPI) provides a framework for peer-to-peer business protocols, implementing RosettaNet (versions 1.1 and 2.0) and ebXML (versions 1.0 and 2.0).

Note: Trading Partner Integration was formerly known as B2B. Some resource names contain abbreviations that are a legacy from prior WebLogic Integration releases. The Trading Partner Integration resources currently retain B2B as part of their names

When you deploy WebLogic Integration to a clustered domain, all Trading Partner Integration resources—with the exception of resources for the administration server—must be deployed homogeneously in the cluster. Targeting Trading Partner Integration resources to all clustered servers in a domain enables you to achieve high availability, scalability, and performance improvements for your application.

For more information about Trading Partner Integration resources and clustering, see Designing a Clustered Deployment. For information about resources that can be configured to accommodate Trading Partner Integration loads, see Trading Partner Management in Managing WebLogic Integration Solutions.

Trading Partner Management Repository

The Trading Partner Management Repository is an important part of Trading Partner Integration. Database operations on this repository and for all of Trading Partner Integration are performed through the JDBCTxDataSource named cgDataSource using the JDBCPool named cgPool.

Note: You can configure the database for your Trading Partner Management Repository to use concurrent access. For information about issues regarding specific databases, see the WebLogic Integration 8.1 Release Notes.

Data Caching

Data from the Trading Partner Management Repository is cached during server startup to improve performance by reducing access to this resource. In a cluster environment, the Trading Partner Management Repository data is cached on the administration server and each managed server. These caches are synchronized through the mechanism shown in the following figure.

Figure 1-8 Trading Partner Management Repository Cache Synchronization

Managing the Data Cache

The WebLogic Integration Administration Console enables you to perform updates, imports, and deletions to the Trading Partner Management Repository. For information about using the WebLogic Integration Administration Console to perform these operations, see Trading Partner Management in Managing WebLogic Integration Solutions.

Trading Partner Integration Initialization and Run-Time Operations

Trading Partner Integration is initialized during server startup by the WLI-B2B Startup EJB.

Warning: The WLI-B2B Startup EJB has an initial-beans-in-pool setting of 1. Changing this value will cause Trading Partner Integration startup to fail.

At run time, outgoing and incoming Trading Partner Integration messages traverse different paths. The following sections describe the paths and process flows for outgoing and incoming business messages.

Outgoing Messages

The following figure shows the path of an outgoing business message.

Figure 1-9 Outgoing Message Path

The preceding figure illustrates the following process flow:

A message is sent from a WebLogic Integration business process using a Trading Partner Integration control (ebXML or RosettaNet).
The Trading Partner Integration layer (RosettaNet or ebXML) uses input from the control (the message, annotations, and so on) and constructs the appropriate message to be sent.
The Trading Partner Integration layer persists this message in the WebLogic Integration document store and forwards it to a JMS queue. RosettaNet and ebXML have their own JMS queues— wli.internal.b2b.rosettanetencoder.queue and wli.internal.b2b.ebxmlencoder.queue, respectively.
Each of these queues has its own message-driven bean(s) listening to the queue. The message-driven beans are WLI-B2B RosettaNet for RosettaNet and WLI-B2B ebXML for ebXML. The pool size of these message-driven beans can be increased as needed to support customer environments that experience high message volume.
The message-driven beans send out the message asynchronously over HTTP(S).
Message tracking information for outbound messages is sent to the Trading Partner Integration message tracking queue, wli.internal.msgtracking.queue. The WLI Message Tracking message-driven bean listens to this queue. It will update the various message tracking tables based on the tracking level set in the Trading Partner Management module of the WebLogic Integration Administration Console.

For information about using the WebLogic Integration Administration Console to set tracking levels, see Trading Partner Management in Managing WebLogic Integration Solutions.

Incoming Messages

The following figure shows the path of an incoming business message.

Figure 1-10 Incoming Message Path

The preceding figure illustrates the following process flow:

A message sent to a trading partner is received by the TPI Transport Servlet Filter, specified in B2BdefaultWebApp/WEB-INF/web.xml. The filter inspects the URL and decides if the incoming request is a TPI URL / request. If it is not destined for Trading Partner Integration, the message continues on to other filters and the final destination servlet.
If it is a Trading Partner Integration message, the filter forwards to the Transport Servlet, WLI-B2B HTTP Transport. This servlet is packaged in b2b.war.
The message is then sent to the Trading Partner Integration decoder. There is a different decoder for each business protocol. The appropriate decoder unpacks the message.
The decoder persists the message in WLI Document Store.
The decoder determines the destination and originator parties, the service name, and other relevant information that helps in dispatching the message.
The message is then dispatched to the Async Dispatcher Queue. If the decoder determines this message is part of a new exchange, a new process instance will be requested. If, however, this message is part of an ongoing exchange, the decoder will request that this be dispatched to a particular receive node within an existing process instance. The message parts will be packaged as appropriate for the receive node's method signature.
The Async Dispatcher Module dispatches the message to the appropriate business process.
Message tracking information for inbound messages is sent to the Trading Partner Integration Message Tracking queue, wli.internal.msgtracking.queue. The WLI Message Tracking message-driven bean listens to this queue. It will update the various message tracking tables based on the tracking level set in the Trading Partner Management module of the WebLogic Integration Administration Console.

For information about using the WebLogic Integration Administration Console to set tracking levels, see Trading Partner Management in Managing WebLogic Integration Solutions.

Application Integration Capabilities and Clients

The following sections describe the major capabilities of WebLogic Application Integration and how clients make use of those capabilities:

• Synchronous Service Invocations
• Asynchronous Service Invocations
• Events

For information about clustering and application integration, see Understanding WebLogic Integration Clusters.

Application integration functionality is integrated in the WebLogic Integration product. In order to use application integration with other components of the WebLogic Platform (such as WebLogic Workshop or WebLogic Portal) you must configure a domain that includes each of those components. For information about creating domains, see Creating a New WebLogic Domain in Using the Configuration Wizard. For more information about deploying WebLogic Platform applications, see Deploying WebLogic Platform Applications.

Synchronous Service Invocations

Use synchronous invocations when the underlying EIS can respond quickly to requests, or when the client application can afford to wait.

The following figure illustrates the flow of a synchronous service invocation.

Figure 1-11 Synchronous Service Invocations

In a synchronous service invocation, a client (for example, a business process) calls the application view (for example, as a control in the business process). The application view calls the adapter using a synchronous Common Client Interface (CCI) request. The service adapter is a J2EE-CA service adapter that actually processes the request.

Note: When a process acts as a client to an EIS, the process is stalled while it waits for the request to complete, tying up a WebLogic execute thread, business process, EJB instances, and other resources. To optimize throughput, consider using asynchronous invocations instead unless the underlying EIS system can respond quickly to the request.

Asynchronous Service Invocations

The following figure illustrates asynchronous service processing in WebLogic Integration.

Figure 1-12 Asynchronous Service Invocations—Programmatic/Custom Client

Note: When using the Application View control from a WebLogic Integration process or WebLogic Workshop Web service, the asynchronous response is delivered directly to the EJB for the process or Web service without being posted to the asynchronous response JMS queue.

The following figure shows the processing that takes place during asynchronous service invocations in a WebLogic Integration process client.

Figure 1-13 Asynchronous Service Invocations—WebLogic Integration Process Client

The preceding diagram illustrates the following process flow:

An application view client instantiates an application view instance:
• In the case of a WebLogic Integration process (described in the preceding graphic), the ApplicationView Instance is encapsulated in an ApplicationView Control instance. Asynchronous requests are tagged with a process handle that allows the AsyncServiceProcessor to route the response back to this process instance.
• In the case of a programmatic/custom client (described in the figure titled Asynchronous Service Invocations—Programmatic/Custom Client earlier in this section), the ApplicationView Instance is used directly.
The application view instance creates an AsyncServiceRequest object and sends it to the wli.internal.ai.async.request queue.
The AsyncServiceProcessor message-driven bean receives the message from the queue in a first in, first out (FIFO) manner. The AsyncServiceProcessor uses the AsyncServiceRequest object in the JMS ObjectMessage to determine the qualified name, service name, request document, and response destination for the application view.
The AsyncServiceProcessor uses an application view EJB to invoke the service synchronously. The service is translated into a synchronous CCI-based request/response message for the resource adapter.
The AsyncServiceProcessor receives the response. The response is subsequently encapsulated into an AsyncServiceResponse object and sent to the response destination provided in the AsyncServiceRequest object:
• In the case of a WebLogic Integration process client, the response is dispatched back to the process handle tagged to the request.
• In the case of a programmatic/custom client, the response is placed onto the wli.internal.ai.async.request queue.
The client receives the asynchronous response:
• In the case of a WebLogic Integration process client, the response is delivered via a callback (onServiceNameResponse) on the ApplicationView control instance.
• In the case of a programmatic/custom client, the client receives the AsyncServiceResponse message as a JMS ObjectMessage and passes it to the AsyncServiceResponseListener supplied in the invokeServiceAsync() call shown in step 2.

Events

Application integration adapters generate events that are consumed by business processes or Web services. Events are then delivered to application view clients through one of two methods:

• Events are delivered to WebLogic Integration process clients through a MessageBroker event channel (named for the ApplicationView and event type for the event).
• In the case of a programmatic/custom client, events are delivered through an EventListener object provided by the client. The event is actually delivered to the EventListener through a JMS topic and JMS MessageListener instance (provided by the ApplicationView instance) on that topic.

The following figure illustrates event processing in WebLogic Integration.

Figure 1-14 Events via Message Broker

The preceding figure illustrates the following sequence of steps for event processing:

An event occurs in an enterprise information system (EIS).
The event data is transferred to the event generator in the adapter instance. The details of this transfer and the data transferred are adapter-specific. The event generator transforms the EIS-specific event data into an XML document and posts an IEvent object to the embedded event router instance in the adapter instance. The event generator and embedded event router instance together constitute the event connection for an adapter instance.
The event connection passes the IEvent object to all registered ApplicationView event subscription objects that have indicated interest in this event type. Subscription objects are registered at application view deployment time.
The event subscription object delivers the IEvent object to both the MessageBroker event channel for the event type (named for ApplicationView/event) and the wli.internal.ai.event JMS topic.
Clients receive the event by one of two methods:
• WebLogic Integration process clients receive the event through the event channel.
• Programmatic/custom clients receive the event through an EventListener instance provided by the client. The EventListener instance is called from a JMS message listener registered on the event topic.

Relational Database Management System Resources

WebLogic Integration relies extensively on database resources for handling run-time operations and ensuring that application data is durable. Database performance is a key factor in overall WebLogic Integration performance. For information about database tuning requirements associated with WebLogic Integration applications, see Preparing Your Database and the database-specific notes in Maintaining Availability.

For additional information on turning your database, see your database vendor's documentation.

Hardware, Operating System, and Network Resources

Hardware, operating system, and network resources play a crucial role in WebLogic Integration performance. Deployments must comply with the hardware and software requirements described in the WebLogic Integration 8.1 Release Notes.