17-32 Developers Guide for Oracle Application Integration Architecture Foundation Pack
If the values provided by the source application for these fields and the trading partner names in Oracle B2B do not match, you can maintain a DVM file that contains
the mapping between the source applications trading partner IDs and trading partner names of Oracle B2B.
This DVM can be looked up during the transform from the ABM to the EBM in the requester ABCS to populate the SenderTradingPartnerTradingPartnerID and
ReceiverTradingPartnerTradingPartnerID fields.
17.7 Step 6: Deploying and Configuring AIA Services
The next step, as shown in Figure 17–36
, is to deploy the AIA services. You can deploy the services to a target Oracle SOA server using Oracle JDeveloper.
Figure 17–36 Step 6: Deploying and Configuring AIA Services
If any DVM and configuration files are used by the AIA services required for the outbound integration, you must enter data corresponding to your B2B configuration.
You can also use the Project Lifecycle Workbench application to create a bill of material XML file for the AIA project, which can be used to autogenerate a
deployment plan. This deployment plan can be used to deploy all of the AIA services and resources that make up the integration project in multiple development, test, and
production environments.
For more information about generating bills of material, see Chapter 2, Working with
Project Lifecycle Workbench. For more information about generating deployment plans, see
Chapter 6, Generating Deployment Plans and Deploying Artifacts.
In addition, configure the AIA Error Handling framework and set up appropriate roles to be notified of errors in AIA flows.
For more information about error handling, see Setting Up Error Handling in Oracle Fusion Middleware Infrastructure Components and Utilities Users Guide for Oracle
Application Integration Architecture Foundation Pack.
17.8 Step 7: Testing and Verifying
This section includes the following topics:
■
Section 17.8.1, How to Test Using CAVS
■
Section 17.8.2, How to Test Using Dummy Trading Partner Endpoints
Developing and Implementing Outbound B2B Integration Flows 17-33
The next step, as shown in Figure 17–37
, is to test your newly developed or deployed AIA services that make up the B2B integration flow.
Figure 17–37 Step 7: Testing and Verifying
Before you go live with your B2B integration flows with your trading partners, we recommend that you complete the following sequence of tests.
17.8.1 How to Test Using CAVS
If your AIA services are Composite Application Validation System CAVS-enabled, you can test your AIA services using a test simulator.
Using a CAVS simulator, you can simulate the behavior of your trading partners by sending messages to and receiving messages from a test harness, instead of your
actual trading partners. This testing can take place without any knowledge of your trading partners.
The objective of this testing, as shown in Figure 17–38
, is to verify that the AIA services are properly developed, deployed, and configured.
Figure 17–38 B2B Integration Flow Test Using CAVS
17.8.2 How to Test Using Dummy Trading Partner Endpoints
This section includes the following topics:
17-34 Developers Guide for Oracle Application Integration Architecture Foundation Pack
■
Section 17.8.2.1, How to Test Using the Production Code Value Set to Test
■
Section 17.8.2.2, How to Test Using Dummy Business Data Another common approach to testing is to create dummy delivery channels in your
trading partner setup, as shown in Figure 17–39
. For example, instead of configuring your trading partner agreement to send outbound documents to the remote trading
partners server, you can configure the agreement to create the outbound B2B files in a temporary B2B file location on the server.
Figure 17–39 B2B Integration Flow Test Using Dummy Trading Partner Endpoints
In this case, if you test an outbound B2B flow, all of the components involved in the flow are invoked, but the generated B2B document is copied to a temporary file
directory. You can review the B2B document for completeness and correctness and also share it for review with your trading partners.
■
The objective of this testing is to verify the integration between AIA services, the application, and B2B and to verify that the configuration across these layers is
consistent.
■
This testing can also take place without any knowledge of your trading partners.
17.8.2.1 How to Test Using the Production Code Value Set to Test
Certain B2B document protocols support a protocol envelope-level flag that can be used to specify whether the B2B document is being sent in test or production mode.
The trading partner agreements in Oracle B2B can be configured to set this indicator to Test mode.
Now when you trigger an outbound B2B flow, the document is sent across to your trading partners, but the trading partner system recognizes the inbound document as
a test instance and does not pass it on to the backend application, as shown in Figure 17–40
.
Developing and Implementing Outbound B2B Integration Flows 17-35
Figure 17–40 B2B Integration Flow Test Using the Product code Value Set to Test
The objective of this testing is to verify the handshake between your B2B server and the trading partners B2B server. Setup of transport and messaging features such as
acknowledgement, encryption, packaging, partner and document identification, and so forth are verified.
This approach requires that this test mechanism be discussed and agreed upon with each of your trading partners.
17.8.2.2 How to Test Using Dummy Business Data
Finally, you can test integration from your production systems to your remote trading partners production systems by using dummy business data in the B2B documents
being exchanged. For example, if you need to test end-to-end outbound Purchase Order integration from your buyer system to your trading partners vendor system,
which are integrated by an outbound EDI X12 850 B2B flow, you can place orders either using an EDI test item created for the trading partner or using a price of one
cent for the items being ordered.
The order request is received and processed successfully by the trading partners business application, as shown in
Figure 17–41 , however, the trading partners
business users or rules discard the order request.
Figure 17–41 B2B Integration Flow Test Using Dummy Business Data
This approach also requires that the test mechanism be discussed and agreed upon with each of your trading partners.
17.9 Step 8: Going Live and Monitoring
This section includes the following topics:
■
Section 17.9.1, Monitoring Using Oracle B2B Reports
■
Section 17.9.2, Monitoring Using Oracle Enterprise Manager Console
■
Section 17.9.3, Monitoring Using Error Notifications
17-36 Developers Guide for Oracle Application Integration Architecture Foundation Pack
The final step, as shown in Figure 17–42
, is to go live with your trading partner for the outbound B2B document flow. The AIA and Oracle B2B deployments are duplicated in
the product servers and rolled out to the end users.
Figure 17–42 Step 8: Going Live and Monitoring
17.9.1 Monitoring Using Oracle B2B Reports
Oracle B2Bs built-in reporting allows for the creation of the reports listed in Table 17–9
. These reports query the run-time transactions in Oracle B2B and can be used to monitor individual transactions with trading partners.
Oracle B2B allows reports to be created and saved as report definitions, which can be used to generate reports for specific criteria, such as View Purchase Orders exchanged
with trading partner Global, for example. You can also create ad hoc reports.
Table 17–9 Oracle B2B Report Types
Report Type Description
Example Report
Business Message Report These reports provide
business messages based on specified search criteria.
View all Purchase Order documents received from
trading partner Global Wire Message Status Report
These reports enable you to query for wire messages in the
native data formats sent to and received from trading
partners. Wire message reports contain transport and
protocol-related information in addition to the business
data. View all messages sent to
trading partner ABC Corp including the HTTP headers.
Collaboration Status Reports These reports help you group
related individual transactions that together perform a
business task.
This report is supported only for the RosettaNet document
protocol. View all RosettaNet 3A4
collaborations.
Error Reports These reports help you
monitor all failed transactions in Oracle B2B
View all messages received from trading partner Global
that failed in Oracle B2B due to any error.
Developing and Implementing Outbound B2B Integration Flows 17-37
For more information about how to use the reporting functionality in B2B, see Creating Reports in Oracle Fusion Middleware Users Guide for Oracle B2B.
17.9.2 Monitoring Using Oracle Enterprise Manager Console
Oracle Enterprise Manager Console can be used to monitor the AIA flows. To monitor the outbound B2B integration flows, you can log in to the Oracle Enterprise Manager
Console and look for instances of the requester ABCS that triggered the B2B flows.
The status of the ABCS instance, payload, and child processes can all be monitored from the Oracle Enterprise Manager Console.
By looking up the instances of the composite AIAB2BInterface[1.0], for example, you can view the JMS payload being passed to Oracle B2B, including the various B2B
header parameters.
17.9.3 Monitoring Using Error Notifications
In the case of failures in either the AIA layer or Oracle B2B, the AIA Error Handler gets triggered. The AIA Fault Message contains the error text and description. In addition,
B2B information pertaining to the failed transaction, such as Sender, Receiver Trading Partner, Document Type, and so forth, are also supplied in the AIA Fault.
For more information about error notifications, see Using Error Notifications in Oracle Fusion Middleware Infrastructure Components and Utilities Users Guide for Oracle
Application Integration Architecture Foundation Pack.
17-38 Developers Guide for Oracle Application Integration Architecture Foundation Pack
18
Developing and Implementing Inbound B2B Integration Flows 18-1
18
Developing and Implementing Inbound B2B Integration Flows
This chapter discusses the following topics:
■
Section 18.1, Introduction to Developing and Implementing Inbound B2B Integration Flows
■
Section 18.2, Step 1: Identifying the B2B Document and Analyzing Requirements
■
Section 18.3, Step 2: Adding Inbound Routing Rules to an AIA B2B Interface
■
Section 18.4, Step 3: Developing a New Requester B2B Connector Service
■
Section 18.5, Step 4: Developing or Extending an Existing Enterprise Business Service
■
Section 18.6, Step 5: Developing or Extending an Existing Provider ABCS
■
Section 18.7, Step 6: Configuring Oracle B2B and Defining Trading Partner Agreements
■
Section 18.8, Step 7: Deploying and Configuring AIA Services
■
Section 18.9, Step 8: Testing and Verifying
■
Section 18.10, Step 9: Going Live and Monitoring
18.1 Introduction to Developing and Implementing Inbound B2B Integration Flows
Figure 18–1 shows the high-level steps involved in developing a simple inbound
business-to-business B2B flow from an application to trading partners using Oracle Application Integration Architecture AIA.
18-2 Developers Guide for Oracle Application Integration Architecture Foundation Pack
Figure 18–1 High-Level Steps to Develop and Implement a Simple Inbound B2B Flow
Most of the preceding steps are already described in Chapter 17, Developing and
Implementing Outbound B2B Integration Flows. This chapter will be referred to
whenever applicable.
18.2 Step 1: Identifying the B2B Document and Analyzing Requirements
