|
|
|
|
|
You cannot have two Actions
with the same name in the
same Process, regardless of the
Action they start at.
|
|
|
If you try, you will get an error
message.
What is less obvious is that
you cannot have a Stage
named the same as any Action
either. This is not intuitive.
|
|
You can, however, have any number of actions and Stages with
the same Caption. The usability will not be affected at all, just
the underlying names.
|
|
|
|
|
The Process properties are
identical with our well-known
Map, apart from one crucial
difference. The ‘Name’ of the
map has to follow the new
object naming conventions,
namely no spaces,
alphanumeric and underscores
only, and cannot start with a
number.
|
|
We are now, however, allowed to name the Process Caption
anything we want, even with quotes should we wish. This is what
the users will see in the Client. The concept is similar to the
field name and field caption that we are used to on forms.
The reason is that we can use different languages to name this
and all elements of the Process. More on that later when we
discuss the language options. For now it is great to know that we
can have any name we like for a Process, regardless of the
underlying table. This is something that we have needed, and
been asking for, for quite some time, and it is very welcome.
|
|
|
|
|
One extremely important
addition is the strong typing we
get from the new architecture.
|
|
In previous versions there was a tendency to add a prefix such as
‘txt’ to the variable name to denote the variable type (as well as
other odd and flawed conventions such as the field type). This
was often useful as the Metastorm BPM system was not strongly
typed.
Now, as we can see, you can both determine the type of a
variable at any time, and the system will not allow invalid implicit
conversion to be set. At last we can drop the prefix of variables,
we feel, as it is now redundant.
|
|
|
|
|
|
1. Designer User Interface
