|
|
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
