|
|
Business Objects, which we
shall cover in more detail later,
are the mechanism for
Processes are able to read and
store data, among other things.
Each Process and Sub-Process
will have its own default
Business Object created
automatically. This corresponds
to the table where variables
are stored, named after the
Process Name. This is
essentially the same as
previous versions.
|
|
|
What is different is that we can
access any other Business
Object merely by dragging it
onto the Process map. In the
case shown, we are adding the
Sub-Process Business Object.
|
|
|
A new instance of the Business
Object is created and you can
refer to it from the ‘Other
Business Objects’ pane. Here
you can also set the parameter
used to reference the data,
although in many cases the
default is sufficient.
|
|
|
What is more interesting still,
is that the same approach can
be taken for Sub-Processes. As
the layer has been extracted,
we can use it in many different
ways.
|
|
|
Here, we add the Business
Object for the containing
Process (we have to decide
what is valid, or the run-time
Business Object will read and
write nothing).
|
|
|
You can see here that we can
now reference, ie read and
write to, data from the
containing Process. In the past,
as we had no reference, this
was impossible (we could in
fact do it, but all validation
would fail).
|
|
|
Now we are going to add a
linked process. I add another
Process, ‘Process1’.
|
|
|
We then add a Linked Process
Stage (previously known as a
‘Sub-Procedure’ Stage), and
select Process1 as the Linked
Process.
|
|
|
As we are used to, a Flag is
created in the linked Process.
|
|
|
Again, what we are not used to
is the ability to add the Parent
Process Business Object by
dragging it to the Process map.
|
|
|
Notice the default of the
FolderId is set.
|
|
|
We merely need to change that
to the Folder Parent like so …
|
|
|
|
|
|
… and we now reference the
data from the Parent Process
directly. SQL is no longer
required.
|
|
|
As an example, using the
Formula Builder…
|
|
|
… we can set the child Folder’s
subject to Variable1 from the
Parent Process.
|
|
|
|
|
This is something we could never do before without extensive
SQL. This has been a major drawback in the previous ‘Sub-
Procedure’ architecture that has caused difficulties for many
versions.
What is fairly obvious is that you can also set these variables.
What may not be clear is that this bypasses the standard
Metastorm BPM transaction management. As such, there is a real
possibility the data could be overwritten, or possibly you could
create a deadlock.
Use wisely, and treat as a loaded gun, I would say. Having said
that, it is enormously powerful, and especially useful when used
safely to read variables.
What is not clear is what happens when multiple records are
returned. We assume the first will be selected.
In our forthcoming section on Business Objects and Connectors,
we shall demonstrate some real examples of design using
concepts such as this to enhance functionality and make
development easier and more robust.
|
|
|
|
|
|
1. Designer User Interface
