The runtime environment of Partner Gateway consists of the following components:
Figure 4 shows how the components work together:
The sections that follow describe in more detail the runtime components as well as other key elements of WebSphere Partner Gateway.
The Receiver component accepts documents from community participants and from back-end systems and stores them. Specifically, it:
Receivers are responsible for accepting the inbound document from a particular transport. The Receiver records any transport-specific data (for example, the source IP address and certificate information about the SSL connection) to the metadata file and completes any transport-specific technical acknowledgment (for example, sending a 200 response to an HTTP POST).
The Document Manager retrieves stored data, processes it, and routes it, both to community participants and to enterprise systems. Specifically, it:
The following sections describe how the subcomponents of the Document Manager perform the tasks presented in the previous list.
The Document Processing Engine performs all of the processing of documents. The Document Processing Engine is responsible for:
The State Engine encapsulates the business rules on a per-protocol basis and executes instructions based on those rules (for example, initiating a retry when no acknowledgment has been received in the defined interval).
The Alert Engine monitors activity and generates e-mail notifications. You can configure the Alert Engine to specify which alerts are generated, to whom the alerts are sent, and when the alerts are delivered.
The Delivery Manager component is responsible for transporting documents to specific destinations, maintaining a separate queue of documents for each destination. A dedicated transport mechanism exists for each destination, so problems delivering to one destination should not affect transport to other destinations.
The Community Console is a Web-based, J2EE application for configuring, administering, and monitoring trading community activities, and responding to events. Its users are primarily: the Community Operator, the Community Manager, and the community participant. The console provides role-based access control to the various features and views. The features of the console include:
Partner profile information, which is largely read-only once the system is configured. Changes occur only when profiles are added or deleted, or when an existing profile is updated. See Profile for more information.
A gateway specifies the destination information needed for the Document Manager to send a document to the Community Manager or to another participant. See Gateway for more information.
Connections define valid interactions between community participants, one of which is the Community Manager. They include information about the document protocol, document type, sending participant, receiving participant, connection type, and source and destination gateways. The Document Manager uses the information in the connection to determine if translation is required and to determine the destination gateway information. See Participant connection for more information.
A prerequisite DB2 Universal Database Enterprise or Oracle database is used as the data repository. It is used to store data that can be classified in two broad categories: profile information and state management information. The database stores partner profile information and event logs. A single document exchange results in the logging of many events to capture the state transitions of the document.
All information configured through the Community Console is stored in the database.
The data repository is also where guidelines and maps (for validation and translation) are stored, where the state of various processes is recorded, and where trading activity is tracked.
The information stored in the data repository is used by Partner Gateway to provide the administrator with visibility into the entire trading community.
The information stored in the data repository is used by Partner Gateway to provide the administrator with visibility into the entire trading community.
Note that some information (for example, the raw message data in the non-repudiation and message stores) is kept on the shared file system, as described in File System.
The database is used to store the following types of information.
The following security information is stored:
Alerts are defined at a participant level and consist of a variety of attributes to describe event-based alerts or volume alerts.
You can define event-based alerts so that they will be triggered each time the event occurs or so that they will batched, based on an interval. You can also configure the alert with a contact list for notification based on a defined schedule.
Partner Gateway logs information to describe documents as they are routed. Details are logged about the document as it was received and as it was transmitted. The following types of information are logged:
Partner Gateway uses events to track activities and logs the events in a central event log. The events, which are classified as Informational, Warning, or Critical Errors, can be generated by different components in Partner Gateway.
Events can be tied back to document activity when they are in relation to a document that was routed by Partner Gateway. The events can also track non-document related activities, such as logging into the system.
Partner Gateway summarizes key metrics, which can be displayed in the console. The information that is summarized includes:
These counts are rolled up by hour and can be correlated back to the document activity logs.
The following information is stored in the shared file system:
Documents are stored on a disk that has shared access from all components of Partner Gateway (Receiver, Console, and Document Manager). Both the original document (as it was received) and the final document (as it was sent) are stored.
Documents are stored in an unencrypted form for displaying to the console. This disk also has shared access from all components of Partner Gateway (Receiver, Console, and Document Manager).
Communication between some components is done using JMS. JMS queues with reliable storage allow the flexibility of locating components on different machines while still maintaining a standard inter-component communication method.