Building a BPEL Process Data Structure
One of the questions I get asked is how does one go about building a new BPEL process. So I thought I would put down some thoughts on one way of building the process. This approach was suggested by one of my colleagues, Matt Wright, who is a firm believer in use cases being used to define the business process. This isn't the only way to define a BPEL process and in the future we might look at some other approaches.
Use Case Analysis
A good place to start is by defining bascially what you want to achieve by sketching out a use case. This can be done formally using UML use case diagrams in JDeveloper, or it can be sketched out in a word document. The BPEL process will be what happens within the use case and the interactions with actors will be the interfaces to the process, or the partner links. Sometimes what initially looks like an actor will turn out to be another sub-process with multiple actors involved, such as an interaction to "obtain approval".
The high level process description obtained this way can be sketched out using JDeveloper's BPEL designer tool, using scopes for individual steps within the process.
Screen Design
Once we have our basic flow the next question is what do the interactions look like. A good way to think about this is in terms of the screens or messages that will be passed into and out of the process. From our analysis we know the interactions that will occur so at this stage we ask ourselves what information will be needed to perform the actions required of the process.
We can sketch out these pieces of data in the form of an XML schema. This will then be the basis of our internal data structures in our BPEL process.
Building an XML Schema
Creating the Schema File
To create an XSD we use JDevelopers Schema Editor. First we create a new XSD in the same project we used for our BPEL.
We set the namespace to be something suitable, any old URL will do, but it helps if it makes some sort of sense, for example I work in UK pre-sales consulting and so I set the namespace to be "http://www.oracle.com/uk/presales".
Creating a New Type
We then need to define some types, which we do by dragging across a complex type from the component palette and dropping it under the example element provided by default. We then rename the type to something sensible, such as SalesOpportunityType.
We can then define the elements within the type by first adding a sequence, and then putting the individual elements we need within the sequence. We can set the type of each individual element within the tool by right clicking and selecting "set type".
In our example we have given our sales opportunity a name, a deal size, a customer and a description. This is about as simple as a complex type gets. Lets look at a more complicated complex type.
Extending an Existing Type
We need to have types to hold saleman and pre-sales consultants. Both of these types are really different types of person, so we create a person type and then create a salesman type that extends the person type. We could now add additional attributes to the salesman.
Creating a More Complex Type
Lets look at how we can create more complex types by building up from the types we have already created. We can create a sales engagement type that has a sales opportunity and a salesman as sub-elements. The sales consultants are more interesting (I would say that wouldn't I!) as there may be none, one or more sales consultants associated with a sales engagement. We model this in the XSD by setting the cardinality of the Sales Consultant element in the property inspector.
Creating the Elements
We have now almost finish our schema definition. We just need to add a few high level elements and set them to be the appropriate type.
Fluff
One of the things I like about the XSD editor is that I can work how I want to. At times I find it easier to drop into the source code view, particularly when I am cutting and pasting so that I can verify I am getting exactly what I want.
If I have assigned a type to an element then I can either edit that type as part of the expanded element or I can go to the type definition and edit it there. Saves me jumping around the diagram.
Next
Now we have our basic types we need to create the initial input and output messages into our process. We will look at how to do this in a future blog.
