SOA Suite Integration: Part 2: A basic BPEL process

This is the next in the series about SOA Suite integration with Oracle Utilities Application Framework.

One of the first scenarios I am going to illustrate in this series is building a basic BPEL process using Web Service calls to the Oracle Utilities Application Framework. The scenario is this. I will pass in the userid and the BPEL process will call our the AS-User Web Service we created in Part 1. This is just a basic test and illustrate how to import the Web Service into SOA Suite.

To use this scenario, you will need access to Oracle SOA Suite, access to a copy of any Oracle Utilities Application Framework based product and Oracle JDeveloper (to build the process).

First of all you need to start Oracle JDeveloper and create a new SOA Project to house the BPEL process in.

image

image

For the purposes of this example I will call the project simpleBPEL and verify that SOA is part of the project.

image

I will select "Composite with BPEL" to denote it as a BPEL process. I can also the same process to create a Mediator or OSB project (refer to the JDeveloper documentation on these technologies).

image

For this example I will use BPEL 1.1 as my specification standard (BPEL 2.0 can also be used if desired). I give the individual BPEL process as simpleBPEL (you can use a different name but I wanted to keep the project and process the same for this example). I will also build a Synchronous BPEL Process as I want a response from the Web Service. I will leave the defaults to save time.

image

I have no have a blank canvas to build my BPEL process against. Note: for simplicity I am going to use as much defaulting as possible. In fact I am not going to specify an input schema for the incoming call as I will use the basic single field used by BPEL as default.

image

The first step is to import the AS-User Web Service into my BPEL project. To do this I use the standard Web Service BPEL component from the Component Palette to import the WSDL into the BPEL project.

image

Now the tricky part (a joke), you drag and drop the component from the Palette onto the right side of the canvas in the Partner Links swim lane. This swim lane is reserved for Partner Links that have a Partner Role (i.e. being called rather than calling).

image

When you drop the Web Service onto the canvas the Create Web Service wizard is invoked to ask for details of the Web Service. At this point you give the BPEL node a name. I have used the name RetrieveUser as a name. I placed the WSDL URL from the XAI Inbound Service screen in the WSDL URL. Once you specify the URL you can press the Find existing WSDL's button to load the information into BPEL from the call. You will notice the Port Type is prefilled with the port from the WSDL. I also suggest that you check copy wsdl and it's dependent artifacts into the project if you intending to work on the BPEL process offline. If you do not check this your target application must be accessible when you work on the BPEL process (that is not always convenient).

image

Note: For the perceptive of you will notice that the URL specified in this example is different to the URL in the last post. The reason is for the demonstrations I shifted to a new server and did not redo all of the past screen captures.

If you copy the WSDL into the project you will get an information screen about Localize Files. It is just a confirmation screen.

image

The last confirmation screen is a summary of the partner link (the main tab is locked for editing at this stage).

image

At this stage you have successfully imported the Web Service. To complete the setup of the Web Service you need to set the credentials for the Web Service to use. Refer to the past post on how to do that.

Now to use the Web Service. To call the Web Service (as it is just imported not connected to the BPEL process yet), you must add an Invoke action to your BPEL Process. To do this, select Invoke action from the BPEL Constructs zone on the Component Palette and drop it on the edit nodes between the receiveInput and replyOutput nodes

image

This will create an empty Invoke action.

image

You will notice some connectors on the Invoke node. Grab the node closest to your Web Service and drag it to connect the Invoke to your Web Service. This instructs BPEL to use the Invoke to call the Web Service.

image

Once the Invoke action is connected to the Web Service an Edit Invoke edit dialog is displayed. At this point I suggest you name the Invoke node. It is important to name the nodes straightaway and name them appropriately for you to trace the logic. I used InvokeUser as the name in this example.

To complete the node configuration you must create Variables to hold the input and output for the call. To do this clock on Automatically Create Input Variable on the Edit Invoke dialog.

image

You will be presented with a default variable name. It uses the node name (that is why it is important to name the node before hitting this button) as a prefix. You can name the variable anything but I usually take the default.

image

Repeat the same for the output variable.

image

image

You now have a completed node for invoking the service.

image

You have a very basic BPEL process which contains an input, invoke and output node.

image

It is not complete yet though. You need to tell the BPEL process how to pass data from the input to the invoke step and how to take the output from the service call and pass it back to the service.

You need to now add an Assign node to assign the input to the Web Service. To do this select Assign activity from BPEL Constructs zone in the Component Palette. Drag and drop the Assign activity between the receiveInput and InvokeUser nodes as you want to pass data between these two nodes.

image

image

You have now added a new Assign node to your BPEL process

image

Double clicking the node allows you to specify the name of the node. I use AssignUser to describe that I am assigning user data.

image

On the Copy Rules tab you can specify the mapping between the input variable InputVariable/payload/process/input string and the input variable for the Web Service call. We are passing data from the input to BPEL to the relevant input variable on the Web Service. This is simply drag and drop between the two data structures. In the example, I am using the input to pass to the user element in my Web Service as the user is the primary key for the object.

image

The fields become linked (which means data from source will be copied to target).

image

Almost there. You now need to process the output from the Web Service call to the outputVariable of the client call. I have decided to pass back one piece of data, the name associated with the user by concatenating the firstName and lastName elements from the Web Service call. To do this I will use a Transform as it is not just a matter of an Assign action. It is a concatenation operation. This also illustrates how you can use BPEL functionality to transform data from a Web Service call.

As with the other components you drag and drop the Transform component to the appropriate place in the BPEL process. In this case we want to transform the output from the Web Service call so we want it after the InvokeUser action and the replyOutput action. The Transform component is actually part of the Oracle Extensions to the BPEL specification.

image

Double clicking the Transform node will allow you to name the node.  In this example I used TransformName.

image

To complete the transform I need to tell the product the source of the transformation and the target of the transform. In the example this is the InvokeUser output variable. I also named the mapper file to TransformName.

image

By clicking the + or pencil icon next to the map I can create the map. The mapping screen is shows the source and target schemas for me to map across. As with the assign I can map the relevant elements. In my example, I first map the firstName from the Web Service to the result element.

image

As I want to concatenate the names, I drop the concat function on the call line.

image

I now attach the last name to the function to indicate the concatenation of the field. By default the names will be concatenated with no space. To make the name legible I add a space between the field by clicking the function and adding a space in the call.

image

I now have a completed mapping.

image

I can now save the whole project as my BPEL process is now complete.

image

As you can see the following happens:

  • We accept input from the client (the userid for the call) in the receiveInput step.
  • We assign that value to the input parameters for the Web Service call in the AssignUser step.
  • We invoke the Web Service call to retrieve the data from the product in the InvokeUser step.
  • We take the output from the InvokeUser step and concatenate the names in the TransformName step.
  • We pass back the data in the replyOutput step.

At this point we can deploy the BPEL process to the SOA Suite server. I will not cover this aspect as it really all SOA Suite specific (it is all done via Oracle JDeveloper).

Now we need to test the service in SOA Suite. We will use the Fusion Middleware Control test facility. I will assume that credentials have also been setup as per our previous post (else you will get a 401 error).

You navigate to the deployed BPEL process within Fusion Middleware Control and select the Test Service option.

image

Specify some test data on the payload at the bottom of the Test Service screen. In my case I am returning my own userid information.

image

On the response tab you will see the result.

image

It works. You can verify the steps using the Audit trace facility on individual calls.

image

image

As you can see this is a basic BPEL but you get the idea of importing the Web Service is pretty straightforward. You can create more sophisticated BPEL processes using the full facilities in Oracle SOA Suite. I just showed you the basic principals.

Comments:

Thanks for the write up Anthony. I've been trying to get SOA Suite integrated with XAI services for CC%B, and one of the problems that I am running into is the fault handling. I seems that the XAI services don't throw business faults and cannot be caught inside a BPEL process unless you use a runtime fault. When using a runtime fault, for some reason, I cannot get to the fault details in the XAI service's fault, specifically the <ResponseText> which contains the actual fault details. The only thing that I can return is the <ResponseStatus>, and everything drops out after that element.

Have you been able to get a business fault, or get to the fault's ResponseText element so the BPEL process can "bubble" that message up?

Please email me if you have any more details or would like to discuss this.

Thanks.

Posted by rxcanavan on January 26, 2012 at 04:08 AM EST #

Thanks for the write up Anthony. I've been trying to get SOA Suite integrated with XAI services for CC%B, and one of the problems that I am running into is the fault handling. I seems that the XAI services don't throw business faults and cannot be caught inside a BPEL process unless you use a runtime fault. When using a runtime fault, for some reason, I cannot get to the fault details in the XAI service's fault, specifically the ResponseText which contains the actual fault details. The only thing that I can return is the ResponseStatus, and everything drops out after that element.

Have you been able to get a business fault, or get to the fault's ResponseText element so the BPEL process can "bubble" that message up?

Please email me if you have any more details or would like to discuss this.

Thanks.

Posted by rxcanavan on January 26, 2012 at 04:09 AM EST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Anthony Shorten
Hi, I am Anthony Shorten, I am the Principal Product Manager for the Oracle Utilities Application Framework. I have been working for over 20+ years in the IT Business and am the author of many a technical whitepaper, manual and training material. I am one of the product managers working on strategy and designs for the next generation of the technology used for the Utilities and Tax markets. This blog is provided to announce new features, document tips and techniques and also outline features of the Oracle Utilities Application Framework based products. These products include Oracle Utilities Customer Care and Billing, Oracle Utilities Meter Data Management, Oracle Utilities Mobile Workforce Management and Oracle Enterprise Taxation and Policy Management. I am the product manager for the Management Pack for these products.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today