Oracle B2B - Synchronous Request Reply
- by cdwright
Introduction
So first off, let me say I didn't create this demo (although I did modify it some). I got it
from a member of the B2B development technical staff. Since it came with only a simple readme file, I thought I would take some time and write a more detailed explanation about how it works.
Beginning with Oracle SOA Suite PS5 (11.1.1.6), B2B supports
synchronous request reply over http using the b2b/syncreceiver servlet. I’m
attaching the demo to this blog which includes a SOA composite archive that needs to be deployed using JDeveloper, a B2B repository with two agreements that need to be
deployed using the B2B console, and a test xml file that gets sent to the b2b/syncreceiver
servlet using your favorite SOAP test tool (I'm using Firefox Poster here). You can download the zip file containing the demo here.
The demo works by sending the sample xml request file
(req.xml) to http://<b2bhost>:8001/b2b/syncreceiver
using the SOAP test tool. The syncreceiver servlet keeps the socket
connection open between itself and the test tool so that it can synchronously
send the reply message back.
When B2B receives the inbound request message, it is passed
to the SOA composite through the default B2B Fabric binding. A simple reply is created in BPEL and returned to B2B which then sends the message back to the test tool using that
same socket connection.
I’ll show you the B2B configuration first, then we’ll look
at the soa composite.
Configuring B2B
No additional configuration
necessary in order to use the syncreceiver servlet. It is already running when you start
SOA. After importing the GC_SyncReqRep.zip repository file into B2B, you’ll
have the typical GlobalChips host trading partner and the Acme remote trading
partner.
Document Management
The repository contains two very simple custom XML document
definitions called Orders and OrdersResponse. In order to determine the trading partner agreement needed to process the inbound Orders document, you need to know two
things about it; what is it and where it came from. So let’s look at how B2B identifies the appropriate document definition for the message.
The XSD’s for these two document definitions themselves are
not particularly interesting. Whenever you're dealing with custom XML documents, B2B identifies the
appropriate document definition for each XML message using an XPath Identification
Expression. The expression is entered for each of these document definitions under the document administration tab in the B2B console.
The full XPATH expression for the Orders document is //*[local-name()='shiporder']/*[local-name()='shipto']/*[local-name()='name']/text().
You can see this path in the XSD diagram below and how it uniquely identifies this
message.
The OrdersReponse document is identified in the same way.
The XPath expression for it is //*[local-name()='Response']/*[local-name()='Status']/text().
You can see how it’s path differs uniquely identifying the reply from the
request.
Trading Partner Profile
The
trading partner profiles are very simple too. For GlobalChips, a generic
identifier is being used to identify the sender of the response document using the host trading
partner name.
For Acme, a generic identifier is also being used to identify the sender of the inbound request using the remote trading partner name.
The document types are added for the remote trading partner as usual. So the remote trading partner Acme is the sender of the Orders document, and it is the receiver of the OrdersResponse document.
For the remote trading partner only, there needs to be a
dummy channel which gets used in the outbound response agreement. The channel is not actually
used. It is just a necessary place holder that needs to be there when creating
the agreement.
Trading Partner Agreement
The
agreements are equally simple. There is no validation and translation is
not an option for a custom XML document type. For the InboundAgreement (request) the
document definition is set to OrdersDef. In the Agreement Parameters section
the generic identifiers have been added for the host and remote trading partners. That’s all that is needed for the inbound transaction.
For the OutboundAgreement (response), the document definition is set to
OrdersResponseDef and the generic identifiers for the two trading partners are added. The remote trading partner dummy delivery
channel is also added to the agreement.
SOA Composite
Import the SOA composite archive into JDeveloper as an EJB
JAR file.
Open the composite and you
should have a project that looks like this.
In the composite, open the b2bInboundSyncSvc exposed
service and advance through the setup wizard. Select your Application Server
Connection and advance to the Operations window. Notice here that the B2B
binding is set to Receive. It is not set for Synchronous Request Reply.
Continue advancing through the wizard as you normally would
and select finish at the end. Now open BPELProcess1 in the composite. The BPEL process is set
as a Synchronous Request Reply as you can see below. The while loop is there just
to give the process something to do. The actual reply message is prepared in
the assignResponseValues assignment followed by an Invoke of the B2B binding.
Open
the replyResponse Invoke and go to the properties tab. You’ll see that the
fromTradingPartnerId, toTradingPartner, documentTypeName, and documentProtocolRevision
properties have been set.
Testing the Configuration
To test the configuration, I used Firefox Poster. Enter the
URL for the b2b/syncreceiver servlet and browse for the req.xml file that
contains the test request message.
In the Headers tab, add the property ‘from’ and give it the
value ‘Acme’. This is how B2B will know where the message is coming from and it
will use that information along with the document type name to find the right
trading partner agreement.
Now post the message. You should get back a response with a
status of ‘200 OK’. That’s all there is to it.
