Platform

Digg This!

In my first article (WLDJ, Vol. 3, issue 6), I provided an overview of BPM specifications in this area. I described the order change example and the steps needed to create the business process in WebLogic Integration.

In this article, you will see how to create a process application. We can call this application orderChange. In this application we need to create a new process called orderChange.jpd. To start the process, we need to add a ClientRequest received. Next we will add the Web service validate. We will be looking in detail at the steps to create this business process in WebLogic Workshop.

Create New Application and New Process

When you start modeling a business process in WebLogic Integration, you first need to create a business process application called orderChangeprocess, in which you create the business process OrderChange.jpd. When you create orderChange.jpd in the Design View, you will see only the Start and Finish nodes

Create Client Request to Start Process

In WebLogic Workshop there are five different ways to start a business process.

• Invoked via a client request
• Invoked synchronously via a client request with return
• Subscribe to a message broker channel and start via an event (timer, e-mail, file, adapter, etc.)
• Subscribe synchronously to a message broker channel and start via an event
• Invoked via one of several client requests or subscriptions (event choice)

In our example, an XML document is sent with changes to request a ChangeOrder. The XML document has the format of RosettaNet PIP 3A8. Let us call it orderchange.xsd. First add the orderchange.xsd to the schemas folder by importing it in the application. When you add the schema, XML Beans are created. We will look at XML Beans in detail in the next section.

We will use Invoked via a Client Request to start the business process as the client is requesting an order change. To do this, you need to create the method and parameters that your client uses to trigger the start of your business process, which is specified in the General and Receive Data settings of this node. General Settings specifies the method exposed by your business process to clients. Clients invoke the orderChange method to start and make requests on your business process. We map this method to a typed XML, orderchange.xsd. That is, the messages received from clients must contain XML that is valid against an XML Schema orderchange.xsd.The General Settings tab is updated to indicate that you successfully completed the specification of a method name and parameters:

In Receive Data, specify a variable to which an Order Change request, received from a client, is assigned at run time. You can use Variable Assignment mode or Transformation mode. Here, you will assign the XML message received from the client directly to a variable orderChangexsd of the same data type as shown in Figure 1.

The JPD process looks like this:

@jpd:process process::
* <process name="orderchange">
* <clientRequest name="orderChangeRequest" method="orderChangeRequest"/>
* </process>::

The code behind it looks like that in Listing 1.

Add a Web Service

The next step is to call the validateConfig Web service. You can create a Web service control to invoke this Web service. I assume here that you have a WSDL defined for this service. We will create the Web service control through a WSDL. The first step is to import the WSDL into the schemas folder.

When you import the WSDL to the schemas folder of your process application XML, Beans are created. Let's look at XML Beans in detail first.

XML Beans
XML Schema is the starting point for XMLBeans. The XML Schema specification provides a rich data model that allows you to express structure and constraints on your data. In an XML Schema you can enforce control over how data is ordered in a document or how you can constraint particular values (for example, price has to be more than $150.00). To do this in Java you have to write custom code. XMLBeans honors these schema constraints.

Let's take the schema and XML for outValidateConfig shown in Listing 2 and see how it is converted to XMLBeans. This is the output schema for the validateConfig service and specifies if the configuration is valid or not valid and if it is not valid, the error.

You have one complex type element outValidateConfig. In a schema, a complex type is one that defines an element that may have child elements and attributes. The sequence element nested in the complex type lists its child elements. Since outValidateConfig is at the top of the schema, it is a global type.

Within a complex type, outValidateConfig, you use simple types like ConfigID and complex types like Status. The simple type, which is a built-in type, is part of the schema specification. There are 46 built-in types defined in the specification. When you compile XML schema, the resulting API is made up of two categories of types, built-in types that mirror those in the schema specification and others that are generated from user-derived schema types. To compile the XML schema, you can import the schema or WSDL into the schemas directory in WebLogic Workshop; it will create the XMLBeans.

The compiled XML Schema gives you two generated XMLBeans interfaces: OutValidateConfigDocument and outValidateConfigDocument.outValidateConfig. From the schema point of view, the generated outValidateConfig interface represents the complex type you see inside the schema's outValidateConfig element declaration. This complex type translates into a sequence of four elements: Status, Error, ConfigID, and ShipDate. The outValidateConfig interface exposes methods such as getStatus and setStatus to get and set the value status element.

The outValidateConfigDocument interface represents the outValidateConfig document that contains the root outValidateConfig element. XMLBeans create a special "document" type for global element types. A document type provides a way for you to get and set the value of the underlying type, here represented by outValidateConfig. The outValidateConfig element is considered a global element because it is the root element and can be referenced from anywhere else in the schema. To set or get the value of the user defined types get and set methods are provided.

Once we have the XMLBeans, we will create a Web service control from the WSDL. To do this you can add a Web services control with the option of specifying it from a WSDL. Let us look in detail at the control framework.

Control Framework

You can use the control framework of WebLogic Workshop 8.1 to easily connect to and use databases, back-end systems like ERP or legacy systems, custom or vendor applications, and Web services with Java controls. These controls wrap up other controls and add business logic to create reusable, composite components that are part of a business process.

BEA WebLogic Workshop ships with the following controls:

• Web service control: The control can import Web services from their WSDL files, which can be local or dynamically picked up from UDDI server. These controls are interoperable with any .NET or Java Web service.
• EJB control: The EJB control contains the code for JNDI lookups, object creation, and casting steps. EJBs can be invoked through control objects.
• Database control: Enterprise databases are integrated via JDBC through the database control. SQL Maps allow you to indicate how their Java parameters should be replaced into the query.
• JMS control: The client listens on this JMS control via callbacks defined in the client. This control enables publishing and subscribing to queues.
• J2EE CA Adapter control: Enterprise applications and legacy systems can be accessed via J2EE CA adapters, which are controlled by J2EE CA controls. J2EE CA interfaces are integrated with Java through XML maps.
• Timer control: Scheduling for responses and requests can be managed through this control, which triggers the Web service periodically. This enables it to send status updates to the client, poll a data source, or establish a time-out on a request to a resource.

Once we have created the Web service control, we need to specify the call to the validateConfig Web service control in the business process definition. We need to send data specified by the validateConfig method. To do this, we build a data transformation from the data received in the orderchange.xsd to the validateConfig as shown in Figure 2. The code for the data transformation is shown in Listing 3. In Listing 4, the model element from orderchange.xsd is mapped to the model element in the validateConfig method:

The cstic element from orderchange.xsd is mapped to the cstic element in the validateConfig method in Listing 5.

Figure 3 shows the transformation.

Summary

In my next article I will look at how to create decision points and the order status control in the business process. In the fourth article I'll write the change to a file and end the process. I'll discuss process monitoring in the last article in the series.

Reference

BEA WebLogic Workshop Help: http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html.