10g (9.0.4)
Part Number B12121-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Application Server ProcessConnect User's Guide 10g (9.0.4) Part Number B12121-01 |
|
This chapter provides a conceptual overview of Oracle Application Server ProcessConnect.
This chapter contains these topics:
Different users interact with Oracle Application Server ProcessConnect depending on the state of an integration. Table 3-1 describes these users and their responsibilities. The terms used in Table 3-1 are described in detail in this chapter. Oracle recommends that each user read this chapter before using Oracle Application Server ProcessConnect.
|
See Also:
Chapter 1, "A Road Map to Using this Guide" for additional details about the various Oracle Application Server ProcessConnect user types |
Before describing Oracle Application Server ProcessConnect features, it is important to identify several key integration design concepts. Successful integrations are characterized by adherence to these design concepts. By adhering to the design concepts, you can successfully design and maintain an integration, and easily add additional integration parties (known as trading partners or applications). This section briefly describes the following design concepts:
See Also:
Ensure that you design an integration that provides for a single, integrated view of data from different parties that reside within the same enterprise or between enterprises.
Achieving a single, integrated view of data can be challenging. For example, you may need to integrate an SAP application with an Oracle customer resource management (CRM) application. Each application uses its own application interface and data format. The challenge here is to integrate the data from these two different applications into a single view of data. Later on, you may also need to add an additional application with its own unique application interface and data format to this existing integration. The challenge here is to add a new application or trading partner into this existing integration without significantly impacting the data of the current integration of the existing application or trading partner.
Ensure that you design an integration that ensures that parties send and receive messages in the correct sequence. For example, a buying party that sends an airline ticket purchase order request expects to receive an airline ticket purchase order acknowledgment, and not a personal computer purchase order acknowledgment. The mechanism that ensures that the correct messages are sent and received is called correlation. A second example is where a purchase order is sent to a business partner that then sends the originator an acknowledgment. The acknowledgment must update the originator's receivables system. In this case, the acknowledgment from the business partner must be correlated to the originating business process.
Ensure that you design an integration ensuring that data flowing through the integration is correct and in the proper sequence.
Data flows enable data to move through an integration, such as a purchase order request sent from one party to another. Control flows enable you to define the logic for moving data through the system. For example, you can define which data goes first, and in which sequential order, instead of sending all data in parallel.
Ensure that you design an integration that successfully translates the various datatypes in the messages of all parties into a format recognized by your integration software.
Different parties use different syntax to represent data in their messages. This means that the syntax of one party is almost certainly unrecognizable to another party. Translation enables you to convert the syntax of all parties into a syntax recognized by your integration software (for example, conversion of delimited text to XML, or conversion of nontagged syntax to delimited text, and vice versa). When messages are sent out, the message syntax is translated to the original native format of each party.
Ensure that you design an integration that successfully transforms the vocabularies of all parties into a common vocabulary of the integration.
Different parties in an integration use different vocabularies in their business messages. For example, one party may use the term item in its purchase order, while another party may use the term component in its purchase order. This creates a vocabulary mismatch between the two parties.
Transformation enables you to standardize on the terminology used by all parties in an integration and establish a common structure and vocabulary across all parties. Whenever data is sent between these parties, the term item must be replaced by component, and vice versa. Structural changes are also handled (such as an address being presented in a single string for one party, as opposed to being part of a structure for another party).
Ensure that you design an integration that ensures that incoming data is validated for correctness and is valid at all points during integration.
All parties participating in an integration are concerned with the consistency of data being sent or received. A method must exist to ensure the validity of data. Validation ensures that data in an integration is correct.
Ensure that you provide adapters that enable a variety of parties (applications and trading partners) to easily communicate with your integration software.
The interfaces of all parties in an integration can vary greatly. Parties can expose many different interfaces, such as synchronous APIs, asynchronous APIs, databases, screen scraping, Java2 Environment Enterprise Edition (J2EE) connector architecture (JCA), Web services, and so on.
Adapters provide the connectivity that enables parties and their different interfaces to be included in an integration. Adapter types can include the following:
Ensure that you design an integration in which parties electronically agree to and sign off on integrations before deployment in a production environment.
Agreements capture the necessary modeling metadata that governs the communication between partners. Such information can include the communication protocol to use, the security facilities to use, the formats in which data is exchanged, and even the appropriate acknowledgments that are to be sent and received.
To participate in an integration, an electronic agreement between all parties (applications or trading partners) must be created. Before an agreement can be included in an integration, all parties must review the contents and approve the agreement.
Ensure that you design an integration for which you can create business intelligence reports that enable you to analyze integrations.
Oracle Application Server ProcessConnect provides capabilities that adhere to the concepts described in "Integration Design Concepts". This section briefly describes how Oracle Application Server ProcessConnect supports these guidelines.
This section contains these topics:
"Oracle Application Server ProcessConnect Concepts in Detail" for a detailed description of Oracle Application Server ProcessConnect support for these design concepts
See Also:
To support the creation of a single, integrated view of data, Oracle Application Server ProcessConnect uses event-driven business process integration. An event-driven business process integrates business processes based on the data (format and semantics) associated with the business process.
Events are caused or received by parties, and are indications of state changes within parties that require a reaction from other parties. For example, an event to create a purchase order expresses a specific intent, namely to purchase a product. Oracle Application Server ProcessConnect supports the use of three types of events: native, application, and business. Each event type captures the format of event data at a particular moment as it moves through Oracle Application Server ProcessConnect.
Roles and business processes define how events are executed; for example, sending an event requiring user approval from one party to another party. Oracle Application Server ProcessConnect supports the use of five types of roles for managing the various types of events moving through Oracle Application Server ProcessConnect: native, translation binding, application, transformation binding, and business.
Business processes operate at the center of an integration to implement business logic and manage the movement of business events.
By enabling the user to define business processes and business events between parties, the integration becomes independent of the particular end-point semantics in terms of both data and process. This provides organizations with the ability to integrate existing applications and trading partners while providing the flexibility to extend the same in the future as more applications, trading partners, and B2B protocols become available for integration.
Oracle Application Server ProcessConnect supports the concept of native event correlation to ensure that native events correctly match and parties send and receive messages in the correct sequence. The mechanism that ensures that the correct messages are sent and received is called native roles.
|
See Also:
"Native Event Correlation" for a detailed description of how correlation ensures that native events match correctly |
Oracle Application Server ProcessConnect supports the following features:
By separating data flow and control flow, Oracle Application Server ProcessConnect enables you to combine a single data flow with multiple control flows, and vice versa. For example, you may want to process purchase orders through a business process before they are updated in a general ledger system. However, you may want to process purchase orders that are greater than a certain amount differently from smaller purchase orders. Separation of data flow and control flow within Oracle Application Server ProcessConnect allows for the flexibility to keep a consistent data flow while providing for different control flows.
Oracle Application Server ProcessConnect supports the feature of translation to convert the datatype syntax of all integration parties to a syntax recognized by Oracle Application Server ProcessConnect. A specific role, the translation binding role, is provided for performing this task.
Oracle Application Server ProcessConnect supports the concept of transformation for standardizing on the vocabulary used by all parties in an integration. A specific role, the transformation binding role, is provided for performing this task.
|
See Also:
|
Oracle Application Server ProcessConnect supports the feature of native event validation to ensure that before a native event is created, it is validated to prevent the processing of invalid native events. This process occurs before translation of native events in the translation binding role. When an inbound native event has been fully translated to an application event, it is considered fully valid because of the prior native event validation. Before a native event is delivered to an adapter, it is also validated to ensure that invalid data is not sent out.
Further, since Oracle Application Server ProcessConnect captures the data and events in its native format, it is possible to audit or determine which events are not valid and why.
Oracle Application Server ProcessConnect provides adapters that enable applications and their different interfaces to be included in an integration. These adapters enable you to include application, technology, and B2B protocol adapters in an integration. Oracle Application Server ProcessConnect enables the integration of these adapters through a J2EE Connector Architecture (JCA) standard. JCA is a Java standard for building adapters to provide a standard way to access parties through Java. The application interface for all parties must comply to JCA.
|
See Also:
"Applications and Adapters" for a detailed description of adapter support |
Oracle Application Server ProcessConnect supports the creation of an electronic agreement between parties participating in an integration. Parties must approve and sign off on an agreement to participate in an integration. After this agreement is approved, Oracle Application Server ProcessConnect uses the information when the integration is deployed to process events appropriately. Two types of agreements are supported:
"Agreements" for a detailed description of agreements support
See Also:
Oracle Application Server ProcessConnect provides support for creating business intelligence reports about integrations. Oracle Application Server ProcessConnect captures information or state associated with business processes and integrations in a runtime repository. It also provides a number of reporting facilities that provide you with the ability to analyze this information both at an individual level (for example, what happened to a specific purchase order) and at an aggregate level (for example, how many purchase orders have been placed in SAP in the past five days).
Such reports can provide intelligence on a specific event (or business activity), on a specific business process for business process intelligence, or on groups of events, processes, agreements, and errors.
This section describes the key Oracle Application Server ProcessConnect concepts from start to finish, beginning with the arrival of a message from a party (either an application or trading partner) and proceeding onto the deployment and administration of an actively running integration. The following concepts enable you to define integrations within enterprises and integrations between enterprises.
References are provided to sections that describe how to use the Oracle Application Server ProcessConnect user interface tool to implement these concepts.
Integrations consist of the following elements:
The modeler and business administrator use the Oracle Application Server ProcessConnect user interface tool to create and store modeling metadata and profile data in the design-time repository. After the modeling metadata and profile data become part of a deployed integration (known as a configuration), they are stored in the runtime repository.
Modelers and business administrators require the correct set of privileges to perform their specific design tasks in an integration. Oracle Application Server ProcessConnect provides these privileges through use cases. Use cases are the privileges that you assign to a user of the Oracle Application Server ProcessConnect user interface tool.
|
See Also:
|
Modeling metadata concepts are divided into the native, application, and business levels.
This section contains these topics:
This section describes the Oracle Application Server ProcessConnect native-level features. These features are designed to enable you to process events and data in the form in which the external party (either the originating or receiving party) manages the information (for instance, to validate information received from the party to ensure that it is valid).
An event type is an internal definition of business-relevant data that either arrived from a party or is to be sent to a party. An event instance is an actual occurrence of an event type and contains real business data. For example, a specific purchase order for an airplane or a car is represented as a purchase order event instance. Events represent intentions. For example, sending an event to create a purchase order expresses the intent of buying a product. A party reacts to that intention by expressing either to fulfill or not fulfill the purchase order event. Accepting an event establishes an obligation for proper execution.
Oracle Application Server ProcessConnect provides the following types of events, each of which represents a different stage and format of business-relevant data moving through Oracle Application Server ProcessConnect:
Each event has the same structure:
The following sections for descriptions and benefits of the three event types:
See Also:
Oracle Application Server ProcessConnect does not understand the format of data from parties outside its component boundaries. This unrecognizable data format is known as a wire message. Inbound wire messages are received from parties. Outbound wire messages are sent to parties.
Wire messages can be e-mail or queue messages, or synchronous invocations such as a remote procedure call to an SAP system. Wire messages generally follow a message layout defined in message packaging protocols such as multipurpose internet mail extensions (MIME) or marshaling rules in the case of remote procedure calls of programming languages. Other wire messages can follow a particular encoding, be encrypted, and signed, or any combination of these.
Figure 3-1 shows an example of a wire message in SAP IDoc format outside the Oracle Application Server ProcessConnect boundary.
The Oracle Application Server ProcessConnect boundary is established with an Oracle record. Data in the form of wire messages received from a party is represented as an Oracle record on the Oracle Application Server ProcessConnect boundary. An Oracle record to be sent to a party is represented as a wire message.
The Oracle record definition is based on the J2EE Connector Architecture (JCA) 1.0 specification. Data received from a party is represented in an Oracle record instance. An Oracle record instance represents the occurrence of data received from or to be sent to a party. Oracle Application Server ProcessConnect provides a series of adapters that enable communication between parties with their different interfaces and Oracle Application Server ProcessConnect. An adapter creates the Oracle record instance for inbound communication and unpacks the Oracle record for outbound communication.
Figure 3-2 shows the Oracle record on the Oracle Application Server ProcessConnect boundary.
Oracle Application Server ProcessConnect only processes wire messages represented as an Oracle record.
|
See Also:
|
As described in "Wire Messages and Oracle Records", Oracle Application Server ProcessConnect provides a series of adapters that enable parties (and their different interfaces) to be included in an integration. The type of adapter to use and the specific actions you want this adapter to perform are based on the adapter interactions that you add with the Oracle Application Server ProcessConnect user interface tool. Interactions define the communication between the Oracle Application Server ProcessConnect runtime system and various adapters to send and receive data.
Interactions consist of two parts:
Figure 3-3 provides an example of adapter interactions. An inbound adapter interaction is added that reads an expense report from a file (expense001.xml). An outbound interaction is added that writes an outbound expense report notification to a file (notification001.xml) for a notification application.
|
See Also:
"Managing Adapter Interactions" for instructions on adding adapter interactions |
A native event is the Oracle Application Server ProcessConnect internal implementation of the business data contained in an Oracle record. Wire messages can contain a number of sections, such as headers, payloads, and attachments. After the wire message is represented as an Oracle record instance, the event message structure is used. The structure consists of one header plus any number of body elements of datatypes. The different sections are placed into the different body elements of a native event instance, as shown in Figure 3-4. The representation of the contents does not change. For example, a binary data structure sent by a party is still a binary data structure in the body element of a native event instance.
After an Oracle record instance is represented as a native event instance, an important first event abstraction (removal of a native feature of a party's wire message) is achieved. The native event instance's body elements contain the data as sent in the wire message. However, the particular wire message transmission structure is removed (such as encoding, packaging, signing, or encryption). The native data sent by the party is all that remains in the body elements of the native event instance. For this reason, the event classification is native.
In the outbound direction, native event instances must contain the native format for the target party so that the appropriate Oracle record can be created and sent out as a wire message.
Figure 3-5 shows the native event and each of its body elements.
|
See Also:
"Managing Native Event Types" for instructions on managing native event types |
Every party is concerned with the data consistency of wire messages being sent or received. Validation rules are defined that must be enforced to guarantee data consistency. The concept of native event validation is provided for this purpose. Each native event can be supplemented with native event validation rules that you invoke. If the validation rules are satisfied, the native event instance is considered consistent and made available for further processing. If at least one validation rule fails, the native event instance is considered inconsistent. In the outbound case, the native event instance is put into the error state. After it is in an error state, specific error handling is modeled for handling the error situation. In the inbound case, the native event instance is not created and the error is returned to the adapter framework that tries to create the native event instance. The adapter framework is responsible for communicating between the Oracle Application Server ProcessConnect runtime system and various adapters to send and receive data in the form of native events. In the case of a failed native event validation (inbound), the adapter framework always returns an error to the initiating adapter (sending party), which can inform the application about the problem (such as, returning an HTTP error code to the application in the case of the HTTP adapter).
Native event validation rules can access every body element in the native event and can be of arbitrary complexity. This includes checking for the existence of elements, specific values, cross-element checks, enumeration checks, and so on. The native event validation rules enable Oracle Application Server ProcessConnect to guarantee event instance consistency.
Native event validation is not explicitly modeled as steps since the native event validation rules are applied when the native event instance is created. If the native event instance is inconsistent, the native event instance is never placed into ports.
A wire message contains datatypes in their own native format. For example, a payload data section in a purchase order uses datatypes for the quantity ordered, the total cost, the product being ordered, and so on). Oracle Application Server ProcessConnect creates native datatypes for the body elements of a wire message when an adapter interaction is added. However, Oracle Application Server ProcessConnect does not understand these native datatype formats (for example, whether they are scalar or complex types, whether they are string or integer datatypes, and so on). For Oracle Application Server ProcessConnect to understand datatypes, they must be translated into application datatypes.
|
See Also:
|
Wire messages exchanged with parties are generally not one-way wire messages sent in isolation. Wire messages typically follow a message transmission exchange pattern in which a sequence of messages are sent and received between parties.
A native event that is received typically causes another native event to be sent. Or, a native event that is sent causes a response to be received. The initial native event that starts a message exchange is called an initiating native event instance. Other native events are communicated based on this initiating native event. Any number of native events are possible.
For example, an exchange between a credit approval request (CAR) and credit approval acknowledgment (CAA) is described throughout this section. A selling party sends out an initiating CAR native event to check the credit record of a buying party and later receives an inbound CAA native event. Since the wire transmission exchange can be unreliable, additional acknowledgment (ACK) wire messages are exchanged to indicate the receipt of other, previously-sent wire messages. For example, the CAR wire message and the CAA wire message are each acknowledged with ACK wire messages. This results in four wire message exchanges: the CAR, the CAA, and two ACK messages, which results in three Oracle Application Server ProcessConnect native events:
The native roles feature expresses this dependency between native events. The term role is used since the parties exchanging native events (through wire messages) exhibit a specific behavior (role), such as buyer or seller.
The native role defines the exchange behavior of native events between two parties from the viewpoint of one party. Native roles support the modeling of native event exchange behavior. A native role contains a set of internal processing steps that define the processing of native event instances. Figure 3-6 shows a native role for these native events. Table 3-2 describes these events.
Native roles implement native event exchange behavior because they control the specific native event instance to process and the order in which to process them.
The native role implements the buyer behavior. The native CAR is sent out as an initiating event (the first event). At runtime, a native role instance is created for each wire transmission exchange.
By convention, the left side of the native role in Figure 3-6 is the outbound direction to a party. The right side of the native role in Figure 3-6 is the inbound direction to further model elements (introduced later on).
The native role in the end sequences the events to perform the credit approval. Since native events correspond to wire messages, the native role governs their execution sequence.
For these events to respond to one another, a series of key internal processing elements must also be defined. The bottom of Figure 3-6 identifies these elements that enable events to move to and from all roles in Oracle Application Server ProcessConnect.
|
See Also:
"Internal Processing Elements for Native, Application, and Business Levels" for a description of the internal processing elements shown at the bottom of Figure 3-6 |
A selling party that sends out several CARs expects to receive the same number of CAAs (in the normal nonerror case) in return. Each CAR-CAA pair (with the necessary ACK events) is executed by its separate native role instance. After a CAR is sent out, the native role instance waits to receive the CAA. Several native role instances can wait to receive their CAAs. After a CAA is received, Oracle Application Server ProcessConnect determines to which of the waiting native role instances it belongs. If the inbound CAA can be related with its corresponding CAR, the waiting native role instance can be determined, since the native role instance that earlier sent out the CAR is known.
This relationship is called native event correlation. Native event correlation ensures that the right native event instances are matched and provided to the corresponding native role instances. Native event correlation is an expression that defines when two native event instances are related. For example, consider the following expression:
CAR.request_id = CAA.request_id
This expression declares that a CAR and a CAA are correlated if they contain identical credit request identifiers. After a CAA is received, the expression finds the correlated CAR. After this CAR is identified, the waiting native role instance that sent the CAR is identified. The CAA must be given to that native role instance to have the same native role instance process the corresponding CAA for the CAR.
|
See Also:
"Managing Native Event Correlations" for instructions on managing native event correlation |
Some parties represent different business-relevant events within the same message structure. Therefore, the same type of wire message can contain different types of business data. For example, instead of having three different types of payloads for creating, updating, and deleting a CAR, only one type is defined. That type contains a field (sometimes called an action field) that indicates if the contents are a create, update, or delete type.
At runtime, it is also necessary to identify which type is meant, based on the Oracle record. For example, if a purchase order payload is received through a wire message, the Oracle record contains the content. The action field indicates if the purchase order payload is a create, update, or delete type. Based on this type, a native event instance is created that represents either a create CAR, update CAR, or delete CAR.
The concept that makes this distinction is called an event map. An event map consists of an expression for each type of Oracle record that determines the native event type for a given instance of the Oracle record. After the Oracle record is available, the event map applies the expression to it. The expression results in one native event type. After this is determined, an instance of this native event type is created and populated. If an Oracle record maps only to one native event type, the event map is simple. The expression becomes true and the map has only one entry.
|
See Also:
"Managing Event Maps" for instructions on managing event maps |
For the native levels, and application and business levels described in subsequent sections, to respond to one another, a series of key internal processing elements must also be defined. The bottom of Figure 3-7 identifies these elements that enable the events to move to and from all roles. While Figure 3-7 shows a native role, these internal processing elements are also used in application and business roles.
These sections describe the following internal processing elements available at the native, application, and business levels:
A role port represents an input or output parameter of a native, application, and business role containing event instances at runtime. Figure 3-7 provides an example of role ports in a native role. You connect the ports on the left side of the native role to Oracle records (that is, the boundary of Oracle Application Server ProcessConnect) using the Oracle Application Server ProcessConnect user interface tool. The native role ports on the right side are connected to other ports for further processing. The native role shown in Figure 3-7 has four input and four output parameters. Ports are identified by events. The name of each event is shown next to the ports. At runtime, only event instances of this type are permitted in the ports.
Ports are distinguished as follows:
A step defines execution logic in a native, application, and business role that is applied to one or more events. The steps in the native role example in Figure 3-7 do not apply any execution logic. Instead, they send the native event instance without any processing. Steps of this type are called pass-through steps. These steps are useful when no processing other than sending events is required. Other steps perform more detailed processing, such as transformation or conditional branching. With conditional branching, for example, you can specify that a specific condition be performed if the amount field of a purchase order is over a specific number, such as notifying a second approver. A step waits for all control flows and all data flows to arrive before executing its logic. The only exception to this is the Or Step, which executes its logic as soon as the first control flow arrives.
Step ports are the input parameter and the output parameter of steps in native, application, and business roles. The first step has one input parameter and one output parameter, both of event type NE_CAR in the example shown in Figure 3-7 (NE standing for native event).
Data flows connect step ports and role ports of native, application, and business roles. For example, the inbound port of native event type NE_CAR in Figure 3-7 is connected to the inbound step port of the first step. At runtime, the native event instance placed on the inbound role port is made available to the inbound step port. This behavior is analogous to binding actual and formal parameters in method invocations of a programming language.
Data flows from one role to another are grouped together. The set of data flows between a given pair of roles is called a data flow group. A data flow group aids in specifying the role to choose when there are potentially multiple roles to which an event instance can be passed (that is, when there are multiple data flow groups between a given pair of roles).
Control flows between steps indicate their execution order. As shown in Figure 3-7, the control flow relationship and the data flow relationship does not necessarily relate the same pairs of steps. Figure 3-7 contains only sequential relationships that enforce the sequential execution of the steps. More complex control flow relationships such as conditional branching or parallelism are also available.
Control flows also use a guard value to specify the next step to execute based on the outcome of a condition expression evaluation or the outcome of a given step. In the case of condition expressions, the outcome could be true or false. In the case of step execution, the outcome could be success or failure.
This section describes the following Oracle Application Server ProcessConnect application-level features that are designed to enable you to add additional event processing facilities or rules to the event in the semantics of the party, even though the syntax has been converted into the format used by Oracle Application Server ProcessConnect.
For Oracle Application Server ProcessConnect to process the datatype contents of inbound native event body elements, the contents must be re-represented in an interpretable syntactic format. This interpretable format is called the application format. Oracle Application Server ProcessConnect represents the following in application format:
For example, if a CAR is received that is represented as a comma-delimited native format, then Oracle Application Server ProcessConnect cannot extract values from it. However, this is necessary when, based on specific values, control flow decisions must be made later in the business process, or if it must be transformed. After the native event is represented as the corresponding application event, Oracle Application Server ProcessConnect can extract values from it and make decisions based on it, or transform it.
The explicit native format re-representing in application format is called translation. For a given pair of corresponding native event and application event types, there is a translation that re-represents the contents of the inbound native event in the native format as an inbound application event in the application format. For outbound events, this re-representation occurs in the opposite direction (outbound application event in the application format to outbound native event in the native format).
Translation only rewrites the syntax, not the particular datatype values. For example, if the native format contains an address consisting of one long string, the application event contains the same long string content. However, if the native event's address is in binary representation, then the address is in application format in the application event.
Translation is performed by a translator that you select with the Oracle Application Server ProcessConnect user interface tool. Oracle Application Server ProcessConnect provides three types of translators for translating native events to application events, and vice versa. Table 3-3 describes these translators.
|
See Also:
|
The internal structure of application event body elements is defined through application datatypes. Application datatypes represent an interpretable syntactic format understood by Oracle Application Server ProcessConnect. Application datatypes are a structured type system with primitive types such as string or integer and complex type constructors. Translation translates from the native format into the application format defined by the application datatypes. These application datatypes enable Oracle Application Server ProcessConnect to access the contents for further processing.
At this point in the event processing, a second important event abstraction is achieved. The particular native format is removed. By viewing the contents of application event body elements, the particular native format cannot be identified. Any specific syntactic property of a party is removed. For example, any business data originally in binary form in the wire message is removed. Instead, the business content is now represented in the application format, (that is, the Oracle Application Server ProcessConnect-specific XML format). The only specific property that remains is the particular vocabulary a party uses (for example, a product is referred to as car instead of a vehicle in a purchase order).
As with native events, the corresponding application events are sent back and forth between parties in a particular sequence. This sequence is defined in Oracle Application Server ProcessConnect. The same internal processing elements as described in "Internal Processing Elements for Native, Application, and Business Levels" (steps, ports, and so on) are also available with application roles. Figure 3-8 shows the application role. The same symbols are used for roles and events. However, roles that process native events are known as native roles and roles that process application events are known as application roles. Application event names are prefixed with AE in Figure 3-8. In Figure 3-8, the event movement is initiated from within Oracle Application Server ProcessConnect.
|
See Also:
"Managing Role Types" for instructions on managing application roles |
In Figure 3-8, the native role and the application role are not yet connected. Furthermore, the translation steps that translate native events to application events and vice versa are not yet modeled. To model these steps, a translation binding role is required.
The translation binding role connects the native role ports to the application role ports with a data flow. Through this connection, native events are translated into application events, and vice versa. The translation binding role only exists in conjunction with its related native role and application role. The translation binding role is represented as a dashed box in Figure 3-9.
Translation using an XSD, D3L, or token substituted text translator is executed within translation steps in the translation binding role. These steps are prefixed with TL in Figure 3-9.
|
See Also:
|
If the ACKs are only needed in the exchange between a trading partner but not within the enterprise, is there a way to disable inbound ACKs as early as possible and produce outbound ACKs as late as possible to reduce the amount of processing?
The earliest place to disable an inbound ACK is the native role. The ACK must be received from the sending party. Therefore, a role step must be inside the native role that processes the ACK. However, instead of sending it to the translation binding role, it can be disabled within the native role. If this approach is followed, the native role does not pass the native ACK event to the translation binding role.
While this is the most efficient approach, it does not work if the native role is reused for another case where the ACK is needed. Therefore, if reuse is necessary, disable the ACK in the translation binding role. In this approach, the native role preserves its original behavior and the translation binding role in another scenario can again, if necessary, disable the ACK.
Generating an ACK requires access to the events that generated the ACK. The only place currently where event content is interpretable by Oracle Application Server ProcessConnect is the application role (application events) or the translation binding role (the application events in it). Again, a design decision must be made on where to perform the ACK generation. In this example, generation is performed in the translation binding role. Figure 3-10 shows this situation.
The disabling step is known as a consume step and is called DS (for disabling an event and preventing further processing from occurring) in Figure 3-10. The generating step is called GN. To generate the ACK, the generation step needs the original AE_CAA event. Therefore, an additional data flow is added to an input port of the generation step.
Figure 3-10 also shows that the native role remained unchanged (the initial design goal). Also, the application role does not require interaction with ACKs. ACK disabling is confined to the translation binding role.
This example shows the ability to achieve a very important goal: behavior abstraction. The translation binding role abstracted from the ACK handling that was imposed by the particular party that required ACKs. However, the ACKs may not be relevant on the business level (only on the protocol level). This means that with translation binding roles, the transport-related handling of ACKs can be abstracted. As a result, the application role becomes much simpler with fewer modeling constructs.
Behavior abstractions are different from event abstractions. However, both are achieved concurrently by way in which the spoke is modeled with the corresponding event classes.
This section describes the following Oracle Application Server ProcessConnect business-level features:
A third and final event class is called the business event. A business event is required to establish a common event structure and event vocabulary across all parties. For example, if one party uses car and another party uses vehicle in a purchase order to refer to the same product, then a vocabulary mismatch exists between the two parties. Whenever an event is sent between these parties, car must be replaced by vehicle, and vice versa. Transformation corrects this vocabulary mismatch.
Why is a business event required? Why is the transformation not done directly between application events since the application event content is interpretable by Oracle Application Server ProcessConnect? The answers lie in the scalability problem that arises with four or more parties. If four parties exchange events, then two transformations must be defined between each pair of parties. This means 12 transformations in total if direct transformations take place. However, if each of the four parties transforms only to and from a common business event, then only eight transformations are necessary, two for each party. This significantly reduces the number of required transformations. If transformations for 10 parties must be defined, then only 20 transformations are necessary, instead of 90 transformations. The break-even point is with three parties, in which six transformations are necessary.
|
See Also:
|
The different datatypes of parties (applications and trading partners) must all be represented as a single, common set of business datatypes to communicate with Oracle Application Server ProcessConnect and participate in integrations. You can import or create datatypes as business datatypes in Oracle Application Server ProcessConnect. You assign these business datatypes to an event body element of a business event. Business datatypes are the datatypes to which application datatypes are transformed for inbound events. Likewise, business datatypes are transformed into application datatypes for outbound events.
A business event must be defined that represents all corresponding application events from all the involved parties. This means that a common structure must be found between the application events. For example, assume the following:
In what format does the business event appear? The business event has each datatype item in a separate string. Transforming from the application events to the business event for an inbound message means to split the strings into their individual parts where necessary. Transforming from the business event to the application events for an outbound message means to compose strings where necessary.
In addition, a vocabulary must be defined into which all application events are transformed. For each data item, it must be defined if its value can be preserved in the business event or if a vocabulary conversion must take place (such as from car to vehicle). Maps that relate values such as car to vehicle are called domain value maps. A lookup takes place for conversions. For example, given car, the corresponding value vehicle is looked up.
A transformation rule describes how to transform one data item from an application event to a business event, and vice versa. An example of a transformation rule is as follows:
copy(from=HR New Ad-IN/Ad/Ad_ID --->to=Global NP Ad-OUT/PAYLOAD/Ad_ID )
In this example, the transformation rule copies the value from a data item named Ad_ID in a source application event parameter named HR New Ad-IN to a data item named Ad_ID in a target business event parameter named Global NP Ad-OUT. More complex transformation rules such as conditionals, domain value map lookup, and iteration are available.
A transformation map is the set of all transformation rules necessary to transform a business event from an application event, or vice versa. Transformation maps have any number of sources and targets. Sources and targets can be application events, business events, or datatypes.
Transformation maps are separated into event transformation maps and datatype transformation maps. This enables you to reuse the same datatype in multiple event transformation maps.
At this stage, a third important event abstraction is achieved. Business events completely abstract from any party specific properties, including data structure and vocabulary. All related events from all parties follow the same structure and the same vocabulary once they are translated and transformed into business events. Figure 3-11 shows the abstraction levels that lead to an Oracle Application Server ProcessConnect format.
|
See Also:
|
Business events, as with application and native events, are processed in a specific order. The business role defines the execution order, independent of the application roles bound to it. Figure 3-12 shows the business role. In this example, the business event names are prefixed with BE.
|
See Also:
|
Transformation binding roles connect application role ports to business role ports. Transformation steps are located inside transformation binding roles. The transformation step names are prefixed with TF in Figure 3-13.
The roles in Figure 3-13 comprise a portion of a spoke. A spoke consists of a role set extending from the native role to the business process (not shown in Figure 3-13). All roles and event classes up to the business role achieve the three levels of abstraction. The business role is completely removed from any party-specific properties. This includes event characteristics as well as behavior characteristics.
Part of a second spoke is introduced in Figure 3-14 that results in the same abstraction. This can be the case if another party has a different protocol and different types of wire messages dealing with CAR and CAA. To keep it simple, this additional party does not require ACK events, but has a different representation of CAR and CAA. This representation requires its own set of transformations. This is denoted by CAR' and CAA' (note the apostrophes). By adding another spoke, the already-existing spoke remains unchanged. This is important in a business environment where adding and removing parties occurs frequently.
Figure 3-14 shows the required spoke for a second party (located at the top of the figure).
For the additional spoke, the same business events and the same business event sequence are available after the transformation binding role. This enables the business role to be reused, as shown in Figure 3-14. Reuse enables you to avoid having to manually design this role a second time. When designing a business process, this is an important situation because the business processes do not distinguish between party-specific behavior.
|
See Also:
|
The business process is at the center of any integration and implements the business logic and manages the movement of business events. The business process also hides the unique characteristics of each party in an integration. For example, if the amount of the credit approval request exceeds a certain limit, specific steps are taken. For example, the approval of two senior supervisors may be required. This business logic is completely independent of where the request is sent and the particular behavior of a wire message for a given party.
Since business roles ensure homogeneous behavior, structure, and content of business events, the business process is used in a homogeneous environment. Figure 3-15 shows the business process. The business process must later be connected to business roles.
Table 3-4 describes the identifiers in Figure 3-15.
Figure 3-16 links the business process with the business role in Figure 3-14 that implements the behavior for trading partners. Only the business role is displayed, not the entire spoke.
The business process is now connected with the spoke shown in Figure 3-14 for the parties. According to Figure 3-14, two different B2B protocols and their corresponding translations and transformations are available.
An application is the source of the CARs and the target for the CAAs. To connect to the application, another spoke must be modeled in the outbound direction that implements the transformation and translation required for it as well as the wire exchange behavior. This spoke looks similar to the one without the acknowledgments, since the connection to the application is transactional and does not require any transport-level acknowledgments.
|
See Also:
"Managing Business Processes" for instructions on managing business processes |
Events originate from parties and are sent to parties. At some point in event processing, event addressing must be performed. Event addressing enables you to select the target party with whom to integrate in the SetParty step of the business process. There are two methods for performing event addressing:
Figure 3-17 shows an example where a party is set through the SetParty step in a business role. The step SP indicates that a party is set.
As Figure 3-17 shows, an outbound BE_CAR can take two paths since there are two spokes. Which path is taken? Since each path implements a different wire message exchange sequence, the choice must be correct for the target party (in this example, the target trading partner). The party agreement defines which event can be sent to a party using which particular spoke. This agreement is used by Oracle Application Server ProcessConnect to determine which spoke is taken after the business role in an outbound direction.
|
See Also:
|
During runtime, instances of events, roles, and steps are created. These instances go through various states based on their current location in an integration. This section describes these various instance states.
This section contains these topics.
See Also:
Oracle Application Server ProcessConnect persists data being processed. The data that is persisted as events flow through the system are called event instances. Event instances also follow the same classification as event definitions (that is, a native event instance is created when Oracle Application Server ProcessConnect receives an event, an application event instance is created after a native event is translated to Oracle Application Server ProcessConnect's internal format, and a business event instance is created after the application event instance has been transformed to the common (business) view definition).
Each event instance has an event processing state associated with it. As soon as Oracle Application Server ProcessConnect receives an event, it is captured in the design-time repository. Until the event instance is picked up by the integration manager for processing, it is in a wait state. Most often the event instance is processed by the integration manager almost immediately. During processing of the event by the integration manager, the event state is set to active. When processing is complete, the state is set to either consumed or error. If processing is successful, then the state is set to consumed. If there was an error during processing, the state is set to error.
|
See Also:
|
Oracle Application Server ProcessConnect persists data on the processing of events in a business process. At design time, business process behavior is captured as roles. At runtime, Oracle Application Server ProcessConnect creates role instances when processing for a given role is instantiated. Each role instance has state associated with it. When a role instance is created, its state is set to created. The state is set to running when the role instance has events being processed. If the role has completed successfully, then its state is set to completed. If an error is encountered during processing, then the state of the role instance is set to error. If you manually stop a coordination, which aborts all role instances for that coordination, the state is set to aborted. Role instance state is set to WorkflowComplete when all the steps are complete, but the events have not been delivered to the adapter framework or the next role. The state of a role instance is set to AFComplete when all events have been delivered to the adapter framework, but the End step has not executed yet. Role instance is in this state for a very short period of time, since the End step is executed immediately and the state is changed to Completed.
Oracle Application Server ProcessConnect creates instances of steps as they are executed. Step instances also have states associated with them. Step instance states are the same as those for role instances, as mentioned in "Role Instances".
A coordination captures the semantics of a business transaction at runtime. When an event is received from an application or a trading partner, Oracle Application Server ProcessConnect determines if the event instantiates a business transaction (that is, if it instantiates a business process with all its role processing).
If this is the case, then it creates a coordination. A coordination has states associated with it. When a coordination is created, its state is set to open.
The coordination state is changed to closed when all processing has been completed successfully. The state of a coordination is set to aborted if the coordination did not complete successfully. This can happen if an error is encountered in any roles. You can also choose to stop a coordination during deployment; this action updates the state to aborted.
Profile data consists of the following elements:
The various applications that are parties in an integration have their own data formats and interfaces. A method must exist for enabling these different applications to communicate with Oracle Application Server ProcessConnect. Adapters provide the method of communication. Oracle Application Server ProcessConnect supports the following types of adapters:
See Also:
Oracle Application Server ProcessConnect supports the following technology adapters:
The following sections for instructions on performing these adapter tasks:
See Also:
The Oracle Advanced Queuing adapter enables applications to communicate asynchronously with Oracle Application Server ProcessConnect over a reliable, scalable, and secure communication channel. Oracle Advanced Queuing provides an extremely flexible mechanism for bidirectional, asynchronous communication between participating applications.
The E-Mail adapter enables you to integrate an Oracle e-mail application with other applications using Oracle Application Server ProcessConnect. This adapter is useful in environments where e-mail uses the Internet Message Access Protocol 4 (IMAP4) and SMTP transport protocols.
The File/FTP adapter enables you to integrate an Oracle FTP application with other applications using Oracle Application Server ProcessConnect. This adapter is useful in all environments involving the FTP transport protocol or local file system. The File/FTP adapter can monitor inbound messages in the form of FTP files placed on a remote FTP server or on local file systems. The File/FTP adapter also sends messages to remote FTP servers.
The HTTP adapter enables you to integrate an HTTP application with other applications using Oracle Application Server ProcessConnect. This adapter is useful in all environments that use the HTTP transport protocol. The HTTP adapter performs the following tasks:
The Java Message Service (JMS) adapter enables Oracle Application Server ProcessConnect to send and receive messages to and from the queues and topics administered by any JMS provider; the Oracle JMS (OJMS) and MQSeries JMS (IBM) providers are certified with Oracle Application Server ProcessConnect.
The Oracle Database adapter enables you to integrate an Oracle application, typically PL/SQL-based, with other applications using Oracle Application Server ProcessConnect. This adapter is useful in all environments involving Oracle database applications.
The Web Service adapter enables you to interact with a Web service operation selected from a Web Service Description Language (WSDL) document.
Oracle Application Server ProcessConnect supports the following application adapters:
Oracle Application Server ProcessConnect supports a variety of different ways to interface with Oracle's suite of business applications for 10.7 and 11i. These different alternatives include:
Interface tables are Oracle database tables provided through which external systems can interface with many of the modules in Oracle applications. Oracle Application Server ProcessConnect enables systems to Oracle Applications Interface Tables through the Oracle Database adapter.
Oracle Applications BES provides a set of asynchronous messaging interfaces through which systems can raise or receive events from some of the modules in Oracle Applications. Oracle Applications BES events are essentially messages that are placed on Oracle's advanced queuing facility. Oracle Application Server ProcessConnect can both raise and receive events from Oracle Applications BES through its Advanced Queuing adapter.
Oracle Applications modules that are developed in Java and J2EE either as servlets or using Business Components for Java can be interfaced using Web services. Oracle Application Server provides a standard set of tools to publish J2EE Applications as Web services. Oracle Application Server ProcessConnect can integrate these modules through its Web Service adapter.
Oracle Application Server ProcessConnect supports business protocol adapters that enable trading partners to use the RosettaNet business protocol. RosettaNet is a group of leading technology companies that have created and implemented a common set of nonproprietary, XML-based, e-business standards. These standards define how trading partners conduct business through the exchange of business documents over the Internet.
You can define a trading partner to be a party in an integration. A trading partner is an entity that engages in business transactions with another trading partner in an integration between enterprises. There are two types of trading partners:
The host trading partner defines all details with the Oracle Application Server ProcessConnect user interface tool for all trading partners, including:
Oracle Application Server ProcessConnect provides two types of agreements:
For the hosted trading partner to send or receive wire messages, an agreement must be defined. An agreement defines the specific types of native events sent or received from a particular party using the specific types of native roles. You assign a trading partner to an agreement for integrations between enterprises. This single definition of an agreement makes no distinction between the type of party you assign; to the agreement, it is just a party.
A trading partner agreement defines which native events are received from a trading partner and which ones are sent to a trading partner from the viewpoint of the hosted trading partner. A trading partner agreement is established between two trading partners to define their rules of engagement. Only those native events on which both trading partners agree are exchanged through wire messages. If a trading partner sends a wire message that does not result in an agreed-on native event, it is rejected. If the hosted trading partner tries to send a native event to a trading partner and the native event is not defined in a trading partner agreement, the send action fails. This is because Oracle Application Server ProcessConnect enforces party agreements.
|
See Also:
The following sections for instructions on performing the following tasks:
|
An application agreement defines which native events are sent to or received from an application. Oracle Application Server ProcessConnect enforces application agreements and ensures that only the agreed-on events are sent out or received.
|
See Also:
Chapter 15, "Managing Applications and Application Agreements" for instructions on managing applications and application agreements |
After designing the modeling metadata and profile data of an integration, you create and include it in a configuration. For this release, there can be only one active, deployed configuration at any point in time. All business processes in the design-time repository are included in the configuration.
Deployment is a two-step process:
When you create a configuration, the integrity of the modeling metadata and profile data is validated to ensure that it is correct and complete. If validation is successful, the configuration is created.
You can deploy the configuration immediately after validation or at a later time. For this release, options are also available for discarding (deleting) the configuration or exporting the configuration to an XML file.
Chapter 16, "Creating and Deploying a Configuration" for instructions on creating and deploying a configuration
See Also:
A business relationship must go through several preliminary states before parties can conduct business. For example:
Lifecycle management enables you to manage these various states.
This section contains these topics:
See Also:
The modeling metadata and profile data goes through several lifecycle states before business can be conducted. The lifecycle state is the state that modeling metadata or profile data is in at a given point in time. Lifecycle management enables you to manage these states. For example, an agreement (which is defined as profile data) goes through the states shown in Table 3-5:
Modeling metadata is typically defined by only the host trading partner. Therefore, there is no need for an approval.
Figure 3-18 shows the lifecycle states of modeling metadata.
Table 3-6 describes the lifecycle states of modeling metadata in detail.
|
See Also:
|
The profile data states vary slightly from modeling metadata states. Figure 3-19 shows the lifecycle states of profile data.
Table 3-7 describes the profile data lifecycle states in detail.
|
See Also:
"Viewing the State of Modeling Metadata and Profile Data on the Details Page" for details on how these states display on the details pages of profile data |
Deployment lifecycle states indicate the states a configuration goes through during deployment.
Table 3-8 describes the deployment states in detail. The configuration state displays in the State column of the Configurations section on the Configuration page of the Oracle Application Server ProcessConnect user interface tool.
|
See Also:
"Creating a Configuration" for instructions on creating and deploying a configuration |
After an integration is deployed in a configuration, it can be managed from the Oracle Enterprise Manager Application Server Control.
You can perform the following tasks:
You can use the Oracle Application Server ProcessConnect user interface tool to create reports that provide the following details about an integration:
Process monitoring reports monitor the current state of an integration object (for example, an event instance).
Activity monitoring reports analyze specific business activities across integration objects (for example, the total number of event instances sent by a specific party during this quarter).
Process optimization reports monitor business process efficiency (for example, the response time for orders placed by a specific party during the last month).
This chapter describes how various users (systems integration consultants, systems architects, connection managers, event managers, business process managers, business administrators, systems administrators, and analysts) use Oracle Application Server ProcessConnect. Integration concepts are explained, leading to a detailed discussion of Oracle Application Server ProcessConnect concepts in the following areas:
|
 Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|
