|
Oracle® Application Server ProcessConnect User’s Guide
10g (9.0.4) Part No. B12121-02 |
|
|
|
|
Oracle® Application Server ProcessConnect User’s Guide
10g (9.0.4) Part No. B12121-02 |
|
|
|
|
This chapter describes several methodologies for using the Oracle Application Server ProcessConnect user interface tool to design and deploy integrations.
This chapter contains these topics:
Methodologies for Using Oracle Application Server ProcessConnect
|
See Also: Chapter 3, "Oracle Application Server ProcessConnect Concepts" for details on concepts mentioned in this chapter |
Oracle Application Server ProcessConnect provides two different methodologies (sets of rules) for using the user interface tool to design an integration:
These two different methodologies enable you to design the two most common types of integration scenarios in a systematic way. However, the number of different types of integration scenarios in which Oracle Application Server ProcessConnect can be used is highly diverse. For this reason, Oracle Application Server ProcessConnect does not impose a specific methodology on you. Therefore, you can use these methodologies or you can use your own methodology.
The Oracle Application Server ProcessConnect user interface tool provides a flexibility that does not require you to complete all modeling metadata and profile data tasks at the same time or even in a particular sequential order. For example, you can complete all modeling metadata tasks and store the metadata for later use. Or, you can complete a portion of your modeling metadata tasks and complete the remaining tasks later. You can also complete your profile data design tasks ahead of your modeling metadata design tasks. This enables you to design in parallel by dividing up tasks with someone working on profile data tasks such as creating delivery channels, while another is working on modeling metadata tasks such as creating event transformation maps. The approach to follow depends on what is best for your integration environment.
However, if you are designing an integration scenario for the first time or if you are uncertain of exactly how to proceed, Oracle strongly recommends that you follow one of the two approaches described in greater detail in this chapter.
This section describes an adapter-centric methodology for using the Oracle Application Server ProcessConnect user interface tool to create an integration.
This section contains these topics:
Create Roles, Transformation Maps, a Business Event, and a Business Process
Create and Deploy a Configuration
|
See Also: Chapter 7, " Tutorial of an Integration within an Enterprise" for a tutorial that uses the adapter-centric methodology to create a simple integration between two applications within an enterprise |
An adapter-centric methodology approach is designed to enable you to define and model the capabilities of your parties (applications or trading partners), adapters, and delivery channels before creating roles, business processes, and other modeling metadata.
This methodology is useful for environments where:
You have a small number of parties (applications or trading partners).
The business process itself is not complex.
Your endpoint details are clearly known. For example, you know the following:
The parties to participate in an integration (applications or trading partners)
The adapters that enable these parties (applications or trading partners) with their unique data formats and interfaces to communicate with Oracle Application Server ProcessConnect
The actions that you want these adapters to provide. For example, an expense application must submit an expense report to an approval application for approval. The approval application must be able to submit an approval or a disapproval of the expense report to the expense application. With Oracle Application Server ProcessConnect, these actions that you define for your adapters to perform are known as adapter interactions.
The delivery channels that describe the communication capabilities (such as message exchange and security details) to use with trading partner or application adapters
This methodology is called adapter-centric because the behavior of the integration is driven more by the endpoints and less by the business process. Therefore, by first designing the endpoints, the rest of the integration can be defined more quickly and efficiently.
An example of a scenario in which an adapter-centric methodology is the preferred option is when connecting Oracle CRM applications to SAP applications. For instance, taking an order entered in an order entry module of an Oracle CRM application into an SAP financials application using largely pass-through steps between these endpoints. In this case, it is easiest to define the Oracle CRM endpoint through the Oracle Database adapter by way of the Oracle 11i Interface Tables. Then, define the SAP Interfaces by accessing the appropriate BAPIs. Only then do you design the business process.
Before describing the specific steps to follow in an adapter-centric methodology, an overview of the steps is described in Table 6-1:
Table 6-1 Adapter-Centric Methodology Steps
| Step | Description |
|---|---|
| 1 | Create applications and add adapter details for each party. |
| 2 | Create native and application events and select appropriate translators for each party. |
| 3 | Create the roles, transformation maps, business events, and a business process for each party. |
| 4 | Create application (or trading partner) agreements associated with each party.
An integration that includes all modeling metadata and profile data (before creating a configuration) is now complete. |
| 5 | Create, validate, and deploy the configuration. |
You first create your application and add adapter details for each party. Table 6-2 provides references to procedures for performing these tasks:
Table 6-2 Application and Adapter Tasks
| Task | See Section... |
|---|---|
| Create an application | "Creating an Application"
|
| Add an adapter to the application | "Adding an Adapter to an Application"
|
| Add a delivery channel to the adapter | "Creating an Application Delivery Channel"
|
| Add an adapter interaction | "Adding an Adapter Interaction"
Note: When you add a new interaction, you have the option of also creating a native event and application event and specifying a translator. You can create this modeling metadata for this new interaction at this time or specify it for an existing interaction at a later time when you can provide all the required details. |
You then create your native and application events and select translators for each party. Two methods are provided. Table 6-3 provides references to procedures for performing tasks with either method:
Table 6-3 Native Event, Translator, and Application Event Tasks
| Task | See Section... |
|---|---|
| Native and application event creation and translator selection method: |
|
|
"Adding an Adapter Interaction"
|
|
"Creating a Native Event Type"
|
You then create your roles, transformation maps, business event, and business process for each party. Two methods are provided. Table 6-4 provides references to procedures for performing tasks with either method.
Table 6-4 Role, Transformation Map, Business Event, and Business Process Tasks
| Task | See Section... |
|---|---|
| Role, transformation map, business event, and business process creation method: |
|
|
Chapter 9, " Creating Metadata with the Modeling Wizards"
|
|
Chapter 12, " Managing Business Processes and Roles " for creating roles and business processes
"Creating an Event Type Transformation Map" for creating transformation maps "Creating a Business Event Type" for creating business events |
|
Note: The modeling wizards also automatically create the role and business process steps, step ports, step data flows, role ports, role data flows, and control flows. If you do not use the modeling wizards, you must manually create this modeling metadata. |
You then create the business event datatypes once. These are the common datatypes. Two methods are provided. Table 6-5 provides references to procedures for performing tasks with either method:
Table 6-5 Business Event Datatype Tasks
| Task | See Section... |
|---|---|
| Business event datatype creation method: |
|
|
"Managing Complex Datatypes"
"Managing Complex Datatype Members" |
|
"Importing XSD Datatypes"
|
You now create the business event body element to contain the business event datatypes. You previously created the business event without a body element in "Create Roles, Transformation Maps, a Business Event, and a Business Process". Table 6-6 provides a reference to procedures for performing this task:
Table 6-6 Business Event Body Element Tasks
| Task | See Section... |
|---|---|
| Create business event body elements | "Creating an Event Body Element"
|
You now create the transformation rules for each spoke. You previously created the transformation maps without defined rules in "Create Roles, Transformation Maps, a Business Event, and a Business Process". Table 6-7 provides a reference to procedures for performing this task:
Table 6-7 Transformation Rule Tasks
| Task | See Section... |
|---|---|
| Create transformation rules | "Creating a Transformation Rule"
|
You now update the SetParty step in the business process to specify the destination (outbound) party in this integration. Table 6-8 provides a reference to procedures for performing this task:
|
See Also: "Creating an Event Header Rule" for instructions on setting the destination (outbound) party in an event header transformation rule (an alternative to using the SetParty step) |
There are two types of agreements: application agreements for integrations within an enterprise or trading partner agreements for integrations between enterprises. Each application (created in "Create Applications and Add Adapters") or trading partner must be assigned to an agreement. The agreement type to use is based on the type of integration you are performing. Table 6-9 provides references to procedures for performing these tasks:
Table 6-9 Agreement Tasks
| Task | See Section... |
|---|---|
| Application agreement tasks: |
|
|
"Creating an Application Agreement"
|
|
"Creating an Application Agreement"
|
|
"Creating an Application Delivery Channel"
|
|
"Adding an Application Agreement Native Role"
|
|
"Managing Application and Agreement Validation and Approval"
|
| Trading partner agreement tasks: |
|
|
Chapter 25, " Managing Host and Remote Trading Partner Capabilities"
|
|
"Creating a Trading Partner Agreement"
|
|
"Adding Trading Partner Agreement Participants"
|
|
"Adding a Delivery Channel to a Trading Partner Agreement Participant"
|
|
"Adding a Trading Partner Agreement Native Role"
|
|
"Managing Trading Partner and Agreement Validation and Approval"
|
You now create and deploy a configuration that includes all the modeling metadata and profile data you created in previous sections. Table 6-10 provides references to procedures for performing these tasks:
Table 6-10 Deployment Tasks
| Task | See Section... |
|---|---|
| Create and validate a configuration | "Creating a Configuration"
|
| Deploy a configuration | "Deploying a Configuration"
|
This section describes how to use the Oracle Application Server ProcessConnect user interface tool to create a business process-centric methodology.
A business process-centric methodology approach enables you to manually create and customize the capabilities of your business process and business event before defining other modeling metadata and profile data. For example, you may already know your modeling metadata such as transformation details, but do not yet know the parties with which to integrate. You follow this approach instead of automatically creating these components with the modeling wizards. When you later use the modeling wizards, you select the manually-created business process and business event. Details such as the business event body elements and business datatypes to create and the adapters and delivery channels to add can be defined later.
This methodology is useful for environments where:
A complex business process that spans many parties to coordinate the sending and receiving of events. This is called a business process-centric methodology because the behavior of the integration is driven more by the business process and less by the specific endpoints being integrated with each other.
You have multiple applications or trading partners participating in an integration. An example of a scenario in which a business process-centric is particularly useful is the case in which you are processing purchase orders from many trading partners and entering them into the financial ledger of the company. In this case, it is easiest to first model the business process and then model the agreements for each trading partner.
Another scenario in which to use a business process-centric methodology is in the case in which multiple parties are participating in different integrations. However, in each integration, the business process is largely the same except for a few additional steps. For instance, in the purchase order example, each trading partner has some specific approval processes (captured in conditional steps) that must be added to the base process purchase order business process definition.
A business process-centric methodology approach is similar to an adapter-centric methodology approach. This section describes only the differences.
Manually create a business process
You first create a business process manually instead of using the modeling wizards by following the procedures in "Creating a Business Process".
Manually create a business event
You first create a business event manually instead of using the modeling wizards by following the procedures in "Creating a Business Event Type". You do not need to create an event body element or business event datatypes for the business event. You can perform those tasks later.
Use the Create Spoke wizard to create a spoke
You run the Create Spoke wizard by following the procedures in "Create Spoke Wizard". When running the wizard, do not specify to create a new business process and new business event. Instead, specify the manually-created business process and business event. Ensure that you have added your adapter interactions and created your application events and business events before running the Create Spoke wizard.
Create parties (applications or trading partners)
You create your integration parties so they can be used to model the business process (in particular, the SetParty steps). You do not need to add adapters or delivery channels. You can perform those tasks later.
This chapter describes the adapter-centric methodology and the business process-centric methodology. In the adapter-centric methodology, you define and model the capabilities of your parties (applications or trading partners), adapters, and delivery channels before creating roles, business processes, or other modeling metadata. This is useful when you have a small number of parties. In the business process-centric methodology, you manually create and customize the capabilities of your business process and business event before defining other modeling metadata and profile data. This is useful when a complex business process spans many parties.
