The linkage of business data or systems leveraged in a corporate business activity is known as Business Process Integration (BPI). OracleAS ProcessConnect is designed to enable BPI through a single middleware service. Integration can extend beyond internal business processes to suppliers, partners, and customers. The Oracle BAM and BPO capabilities described earlier in this chapter are designed to leverage either OracleAS InterConnect or the newer OracleAS ProcessConnect.
|
In building integrated business processes, the following OracleAS ProcessConnect concepts are especially important:
Profiles
Contain identification and contact information
Parties
Contain organizations within a profile (typically applications or trading partners) that participate in B2B exchanges
Agreements
Contain specific collaborations, roles, and communications options describing how two parties will interact
Events
Contain internal definitions of business data that come from or are sent to a party, including header information on the party from which the event is coming, information on the party to which to send the event, event instance creation time, instance life cycle state, event type definition, and body elements
In BPI implementations, message exchange and data flow (defined as data passed as an event) must be in the correct sequence. Translations and transformations must be recognizable, and data must be validated. Roles define how data flow events are executed. Figure 15-5 shows a typical OracleAS ProcessConnect flow with adapter interactions.
Data in the form of messages is received from a party as an Oracle record. When OracleAS ProcessConnect receives this record, it creates two events:
Native event
Provides an internal representation of the business data
Application event
Provides a translation of native event content in a format that can be interpreted by the OracleAS ProcessConnect
To enable better scalability, a business event can establish a common structure and vocabulary between parties. As transformations then take place to and from common business events, the number of transformations required is greatly reduced because all parties can use the business event as a starting point. This efficiency becomes pronounced when four or more parties exist.
OracleAS ProcessConnect integration projects generally use either an adapter-centric methodology or a business process-centric methodology for development:
Adapter-centric
With this methodology, you model capabilities of parties, adapters, and delivery channels before creating roles or business processes.
Business process-centric
This methodology starts with roles and business process modeling.
In general, Oracle suggests that you choose the methodology that creates the more complex portion of the model first. We describe the OracleAS ProcessConnect modeling tool in the next section and then delineate typical steps taken in development using each methodology.
The following OracleAS ProcessConnect components are used to build, deploy, and maintain a business process integration infrastructure:
Modeling tool
An easy-to-use, web-based business-process modeling tool designed to support the complete life cycle management of BPI, from modeling to deployment to monitoring and optimization
Metadata Repository
An OracleAS ProcessConnect metamodel schema in the OracleAS Infrastructure database
OC4J ProcessConnect
An OracleAS ProcessConnect component that instantiates the modeling tool and is used by the modeling tool to read and write integration definitions in the metadata repository
Adapter Framework (AF)
A J2EE connector architecture framework engine that enables Java applications to read the business process definitions from the runtime metadata repository to adapters and vice versa
Integration Manager (IM)
An event-driven business process execution engine that interfaces to AF
The modeling tool provides a modeling interface to design business processes and to enable business event modeling for common content. The profile section of the tool enables endpoint modeling (endpoints are defined as the physical addresses of trading partners), agreement definitions, and trading partner management. Wizards guide you through end-to-end basic integration, adding end-to-end basic event flows and other event flows, and creating spokes. Version control of integration objects is supported through an update facility.
Parties (e.g., applications or trading partners) are included in the integration through the use of adapters. The adapters can be defined using an adapter exchange protocol for specific tasks or can call specific actionable files. There are three types of OracleAS ProcessConnect adapters:
Technology adapters
HTTP, SMTP, FTP, Oracle database, Oracle AQ, JMS, and Web Services
Packaged application adapters
JD Edwards, PeopleSoft, SAP, and Siebel
Legacy adapters
CICS, IMS/DB, IMS/TM, and Tuxedo
Unlike the older OracleAS InterConnect adapters, OracleAS ProcessConnect adapters are built to the J2EE Connector Architecture 1.0 specification with extensions to support introspection. Figure 15-6 shows how to select an adapter for use with a specific application (or party) through the modeling tool.
A deployment section in the modeling tool provides final validation of process integration definitions (e.g., processes and profiles). Once validated, the tool can deploy the configuration from the design-time repository to a runtime repository.
The deployment engine supports numerous standards, including:
B2B standards (RosettaNet and AS2)
EDI standards (X.12, UN/EDIFACT)
Web Services
SOAP
WSDL
UDDI
Internet transports (HTTP/S, SMTP, FTP/S)
Packaging standards (SOAP 1.1, SMIME 3.0)
Security standards (LDAP, X.509)
Trading partner management (CPP/CPA, TPAML)
|
All actions in the modeling tool are captured in a metadata repository via OC4J ProcessConnect. The repository stores definition models, the results from monitoring of runtime processes, and administrative actions. An export/import utility enables movement of integration model objects from one repository to another, which is a typical procedure when moving from development to production. The object definitions are exported in XML.
Business processes are triggered in reaction to events. Such event triggers might include a state change in a business document, multiple business event communications, certain integration event behavior, or certain event stages such as initiation, progress, and completion. Events are created through the modeling tool or by import of XML schemas. Event services supported include event validation, translation (from one format to another), transformation (e.g., semantics such as one-to-many), mapping where events are similar, and correlation.
The Integration Diagram viewer shows a high-level view of the entire process integration. Pictured in such a view or diagram (see Figure 15-7 as an example) is the business process, other roles ("spokes"), all the endpoint parties participating in the process at every spoke, and agreements in place between endpoints (trading partners) and processes. From this view, you can drill down to a specific event flow diagram.
When run concurrently, events and activities must use different business processes. Real-time monitoring of business events and activities takes place in a reports section of the tool. The administrative section can be linked to Oracle Enterprise Manager for configuration and management tasks.
As we noted earlier, the approaches that Oracle recommends for business process integration using OracleAS ProcessConnect vary depending on the complexity of the business processes. Oracle typically suggests an adapter-centric approach in situations in which business processes are relatively simple, there are a small number of parties, and endpoint details are known.
The adapter-centric approach typically involves using the modeling tool in the following sequence:
Create applications, and add adapter details for each party.
Create native and application events, and select translators for each party.
Create roles, transformations, business events, and business processes for each party.
Create agreements between parties.
Create, deploy, test, and validate the configuration before production.
When more complex business processes are involved, BPI developers use a business process-centric approach. This approach includes the following steps, in this order:
Manually create a business process and business event.
Create native and application events and select translators for each party.
Use the create spoke wizard in the modeling tool.
Create the parties.
Add translators and adapters as needed.