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