So here’s our new article, completing the data definition series. We’ll build the remaining Business and Data Objects as well as build our first web form based on those objects.
Using your data inside the “Request a Parking Space” process
Last time, we saw how we defined the data that will be governed by our Business Process.
Now it’s time to make use of it during the process execution. It’s this data that will be input, manipulated and condition the actual process flow for every process instance.
If you remember from the last article, you had some homework 🙂
You had to build the Parking Space Business Object. Check what you did against our proposal. It should feature the same attributes, give or take a few…
- Space Nr.
- Reservation Start Date&Time
- Reservation End Date&Time
- Reserved for
- Meeting with
- Employee Nr
Important Note: Remember that processes govern data, they don’t keep it. Data is kept in the database. That’s how you have to think.
Again, the purpose of this series is to help business analysts and process owners model and automate processes without writing any code, so we’ll assume that the IT department did their work and expose some services that check if there’s a parking space available for the time slot that the requester wishes to reserve and, if so, returns the information defined in the Parking Space Business Object, and if not, returns an response that indicates all parking spaces are occupied.
Remaining Data Objects
Let’s create our remaining data objects: one for the parking space and one of our special data objects that help us govern the process flow, an instance of the ProcessStatusBO.
Inside the process BPMN diagram, click on the Data Objects option
and create a new process data object called v_parkingSpace, of the type object -> parkingSpaceBO, and another one called v_processStatus of the type object->ProcessStatusBO.
I use the prefix “v_” to indicate that it’s a variable, something that holds data, of my process.
From this moment on, your process has all the data placeholders that it needs.
Now there’s one more step…
Collecting the information
We’ll need to collect the data first, to get the process rolling. There are, in fact, several ways to start processes, but the vast majority will necessarily collect information at the start, either from a user (through a form, …) or from other systems, and places it in the process data objects. In our case, we’ll build a form to collect that information from the requester.
Designing web forms is a breeze since Oracle BPM 126.96.36.199. The frevvo platform was introduced to help business users design the interaction forms themselves, reducing the need for IT to build applications for that specific purpose that typically take a lot of time to be ready, increasing the overall agility and decreasing the time-to-market of a process.
So, to build our own forms, we’ll go into the web forms option in Oracle’s BPM Process Composer, click over the “+” sign and give it a name, for instance RequestInfoFRM.
We’re adopting what we call the “Form first method”, so we’ll design the form first, and let Oracle BPM generate the data structures for itself. Then, we’ll just need to connect these self-generated structures to our own data objects.
There’s also the “Data First method”, that allows you to specify the specific data objects for forms and allows widget auto generation, effectively generating the web form in a single click. You only have to adjust the looks, if you don’t like the way the widgets are placed.
For our form, we’ll collect the information that we defined in our RequestBO.
As you can see, the web form designer has a drag-and-drop interface, which allows even complex forms to be designed in a very short timeframe.
And so, we completed our data object definition and built our first web form for it. On the next post, we’ll look into more detail about web form creation, namely focusing on both form creation methods and looking into the various form widgets. Until then…
Post Header image by Garry Ing