Although Process Design is core to the whole Business Process Management initiative, the 'window onto the Process' for the users is undoubtedly the Forms.
One of the great benefits of Metastorm BPM has been the tight integration between the Forms Designer and the Process Designer. Here we see if this is still the case, and if creating fields, variables and business rules is as easy as it always has been.
Form Properties
| |
![]() | The standard properties we are used to are still there for forms. The only important addition is the Caption. Like the Caption properties for other components and elements, it can be anything you like, and is configurable for different languages (see our future section) |
![]() | Clicking on the ‘When user loads form’ or ‘When user exists form’ property takes you straight into a Visual Script (see our future section). ‘When user exists form’ is presumably only run on form save and seems misnamed. |
![]() | Clicking on one of the three Client Scripts takes you straight to the Client Script editor. Here you can write JScript or VBScript. This is a much better method than the rather clumsy approach in previous versions requiring a function and a call from the relevant Event. You can still do that, if required, however. |
Fields
| |
![]() | At long last we are able to turn of the paging of grids. This is a very welcome change. |
![]() | Paging is in itself useful, but as we have said many times, not when universally applied. Fortunately, when you do set paging, you are able to set the page size at last. |
| This value is only editable through the up and down buttons (not even using the keyboard arrows), you cannot type here. This will require dozens of mouse-clicks every time it is used (RSI, anyone?). I hope this will be fixed soon! |
![]() | The single and multiple clip fields are now separate, which makes much more sense. Changing from single to multiple used to ‘lose’ the reference to the variable which is not intuitive. |
![]() | Form segments appear in the Toolbox, one for each available Segment. These are dragged to the Form like any other field. |
![]() | They remain the same, however, as you are able to simply select another Segment if you wish. |
![]() | You are able to set fields off any edge of the form quite easily. |
![]() | We are not sure if this is by design or not, however. |
![]() ![]() | Labels will now, like Field Captions, just resize themselves as more text is entered. |
![]() | But I can't make it smaller, not even by editing the properties! I assume this is because they are in fact normal fields with no control just a Caption. If that is the case, it could be hard to fix. |
| It is certainly quite amazing that no-one has noticed this yet. Perhaps we are uncommon in providing feedback to users via labels? |
![]() | As with Process map elements, the Caption can be edited in- place. |
![]() | The name itself does not change when you do this, of course. |
Fields and Variables
| |
![]() | The biggest difference we find is that Forms are no longer associated with the Process (formerly ‘Map’). In order to associate a Form with the Process data, you need to drag the automatically created Business Object for that Process to the Form. |
![]() | This creates an instance of that Business Object, with a numeric suffix. |
![]() | Expanding this shows the variables and parameters. We will discuss the parameters in more detail when discussing Business Objects, but they define the record accessed by this instance. |
![]() | We add another Process, and we find we can add the Process Business Object for that too. It is worth noting that any form can be used in any Process. This means they can be shared between Processes, although care must be taken (more on that later). |
![]() | Here I've added a couple of custom Business Objects. One is editable, and one, with a RO suffix, is read-only. Note the different icons, and that the Process Business Objects are editable by default. |
![]() ![]() | The context menu on a read- only Business Object allows you to select (among other things) ‘AlwaysRefresh’. Selecting this is akin to setting a field to ‘is dependent’. Note that you have to set any associated field to ‘is dependent’ to make this work. You can also set the page size for records retrieved. This is only important for grids, I believe. I am not certain what effect this value has for things like dropdown options, if any. |
![]() | Note also that you can add the same Business Object more than once. This may be useful if you want to populate a dropdown with one, and fill fields based on the selection from the dropdown, for example. |
![]() | Here we show the Parameter. For Process Business Objects the default is always the Folder Id. |
![]() | We can change this, however, to be the Folder Parent. This would allow you to retrieve data easily from the Parent Folder without resting to SQL. |
| You can also set this data, thus updating the fields in the database. This bypasses the normal transaction and audit capabilities of Metastorm BPM, so must be used with extreme care. |
![]() | The easiest way to create fields on the Form is to drag them straight from the Business Object instance. The appropriate field type is created. |
| Note that dropdowns and list boxes will always have to be created and have variables linked in a two-step process as they will not be created like this. |
![]() | Here a text field is created, and you can see it is named after the variable (name and Caption), linked to the Business Object and the variable, as well as being made optional. |
![]() | You can also multi-select fields (Ctrl- and Shift-Click) and drag them in one go. A huge time saver! |
![]() | But it gets better – you can choose to have fields or a grid! |
![]() | Here is the result if you select fields. |
![]() | As you can see, all properties are set as if you dragged them one at a time. |
![]() | Now I take some more (from by custom Business Object as it makes no sense from a Process Business Object) … |
![]() | … and select a Grid this time … |
![]() | … and it creates a grid. The fields are all named after the variables, BTW, mine are actually Column1, 2 and three (bad choice, sorry). |
![]() |
| Looking at the Column properties, everything is set as I'd want, all I need to is set the width and title as desired, and perhaps change the behaviour. |
![]() | For the read-only Business Object, when I drag variables across and maker a grid, the fields are correctly read-only. |
![]() | The variable dialog is similar to previous versions, but has a more useful tree interface as opposed to tabbed. You can also add a description for it now. Notice that there is also a Business Object created (called ‘Local’) for each Form. This allows creation of temporary variables for Forms. |
![]() | You can create fields for these Local variables in the same way. |
![]() | |
![]() | You can also create Local variables for Form Segments. This will be extremely useful for reusable functional Form Segments. |
![]() | Form segments are added in much the same way as we added Sub-Processes in the Process map. They appear in the Toolbox, and can be dragged onto the Form. |
![]() | Interestingly, the variables from the Form Segment then become available as a new Business Object instance. |
This could provide significant interaction between the Segment and containing Form, which was not previously possible. As an example you could set a variable on your containing form that hides or displays certain fields in the form segment, if set to be dependent.
Option Lists
| |
| | Option lists have changed quite a bit too. |
![]() | Selecting the ellipsis … |
![]() | … gives you three options. |
![]() | The list of values is any expression that returns a list of values. Typically this will be a set of comma delimited strings. There is no longer a need to have a different delimiter as all strings are now in double quotes. |
| We are not certain how this will affect migrated option lists with different delimiters, however. |
![]() | If you choose a Business Object, you select the Business Object and field … |
![]() | … or two fields for a name- value pair list. |
![]() |
| If you choose a Select statement you can write any SQL or use the Query Builder (see our future section) to generate one. |
Field Grouping
| |
![]() | This is something we took a while to discover, and have yet to see mentioned by Metastorm or in the documentation. You can group fields together. |
![]() | They look awful now (as do Form Segments), but I am sure that will be fixed. |
![]() | The properties are just the group name and size. You can change the size, but I am not sure what use that is. |
![]() | Select ungroup from the Context menu to split them up again for editing. |
Field Layout
| |
![]() | A very nifty feature is the ability to resize multiple fields at once. |
![]() | As you drag one field, they all change. |
![]() |
| You can also use the Layout ribbon with the ‘Size Equally’ item to do this. You can, of course, use all the other items we saw in the Process map. |
![]() | It works however the fields are laid out. |
![]() | |
![]() | For fields with a changeable height, you can change that too. |
![]() | When adding and moving fields, they will try to ‘snap’ to alignment with other fields. It is a bit strange at first, but you get used to it quickly. It is a very quick and easy way to line up new fields. |
![]() | You will get lines to show you what alignment is being attempted, too. |
![]() | The same thing happens when resizing fields as well. A typical scenario is drag a field to the Form and it snaps to align with existing fields. Then you resize it and it snaps to resize to match similar fields. All in two simple movements. |
![]() | Going near to the edge of the Form causes the field to try to snap into place at a reasonable distance. This will add some sorely needed consistency to Form Design! |
Tab Order
| |
![]() |
| There is a ‘Tab Order’ item on the Design menu. This is a toggle button. When toggled ‘on’, you can click on each field in turn to set the tab order. |
![]() | This is the start … |
![]() | … and here I have clicked on a field and it is now the first in the tab order. Clicking on another will make it second, etc. |
![]() | What is more interesting is what happens when fields are grouped. |
![]() | Now the grouped fields are in a ‘tab group’ when setting the tab order. |
![]() | Selecting the group … |
![]() | Sets the tab order of the group (it is hard to see, but it is now ‘1’) and the fields are 1.1, 1.2, obviously). |
![]() | And you can select an individual field in the group to set the tab order within the group. |
![]() | |
![]() | Here I have split the group into two groups. |
![]() | And grouped them into a single group, so I have nested groups! |
![]() | And this is now displayed and functional in the tab order! There seems to be no limit, apart from what is practical. This is very powerful and I am sure we shall be finding many ways to use this feature effectively. |
![]() | It has been pointed out that adding a field onto a large form could be a potential nightmare. |
![]() | |
![]() | As it happens, if you select that field it becomes first … |
![]() | … select again, it becomes second (all the others remain in the correct order relatively). |
![]() | This makes it fairly painless. |
![]() | With grouping it can be even easier. |
![]() | Adding the field to an existing group will automatically add it to the end. The original group becomes a nested group. |
![]() | Ungrouping the fields, selecting the new field and grouping them again as unexpected consequences, however. You would have to reorder the fields in the group at least (and I suspect that oddity will not get fixed |


















































































0 comments:
Post a Comment