Important Activities

There is a detailed description of standard activities in this section. If none of the standard activities provide exactly the functionality required, it is possible to create your own activity. Each activity has specific parameters, input/output parameters and arguments (as described in the 'Activity Parameters' topic).

A list of some parameters and input arguments occurring in more than one activity (the most common parameters/arguments):

• User Names

  One special activity allows a PYTHON script to be run. In this case it is not possible to know exactly which input and output parameters will be required / produced by the activity (since the script can contain any functionality). For this reason, each standard activity facilitates a default input (“in”) and output (“out”) argument, which can be used to process the arguments defined inside the script. To use these default input/output arguments, specify the alternative names according to the code in the script.

  Example: A user wants to pass a value to a script in a variable called 'count'. He refers to the default input argument with the alternative name 'count'. Similarly the default output argument can be used to return data from an activity.

  Note: You also use the same technique to pass and receive values to or from a sub workflow.

  Another special feature is useful when two or more workflow nodes should be time-synchronized to be processed sequentially (not all at the same time). This time dependency can be implemented using the '_time' alternative name.

• Caller

  The calling activity. In other words, the place (window) in Valuemation this activity is started from.

  This is the place in Valuemation from which the current activity was called. Sometimes it is very important to know this information because the behavior of some activities should vary by the place from which it is run.

  Example: When started from a Catalog, the BOEditor is opened non-modally (i.e. the calling dialog should be used in parallel with the editor), while from a relation contained in another BOEditor, the editor should be opened modally. Put differently, the calling dialog is blocked until the called activity has finished). See the 'Modal' (formerly 'Transition Kind') parameter for more information.

• Help Key

  The ID of the Help topic which is to be displayed after the workflow (the activity) has been launched.

• Modal (flag)

  Boolean. Modal (TRUE) or non-modal (FALSE). Modal transition will pass control to the called dialog until it has completed. Non-modal transition allows control to pass between both dialogs as appropriate. When used as an output parameter, modal specifies whether the GUI component was started as modal or non modal.

  Detailed Explanation:

  There is a different kind of transition - a transition in GUI, by which we mean the way the user progresses between two dialogs in Valuemation.

  This is a specified Modal (formerly named Transition kind) parameter of the activity. This is used by most activities that open a GUI dialog.

  The Modal parameter is a Boolean value with the following meaning:

  • True

    Transition is modal. A modal transition between two dialogs implies that the source dialog is blocked while the new one is opened and will not be unblocked until that dialog is closed. For example Information or Error Messages which have Options like Yes / No / Cancel are always modal. Control cannot return to the calling window until the action for this window is complete.

  • False

    Transition is non-modal. Non-modal transition leaves both source and new dialogs open simultaneously. A well-known example of this behavior is editing business objects from the Catalog – here both BOEditor and Catalog are run at the same time.

• Mode

  Sets the mode of the dialog box (Normal/Select or Normal/Wizard). The wizard will guide you through the whole process step by step. The default setting is Normal.

• SharedValues

  Serves for transfer of parameters between workflows and also for data sharing with the parent workflow . Holds a map of values to be shared. It is used with the Action Workflows, which are started from particular Valuemation dialogs (catalogs etc.).

  Detailed Explanation:

  Ideally, workflows should be designed so that as many operations as possible would be completed within one workflow instance. However, this would often lead to overly complicated and thus very specific workflows. Many workflows which are similar in purpose could be created to implement different special cases. In order to achieve this, there needs to be a mechanism to share data between workflows.

  The 'Shared Values Map' is a map of values for transfer / sharing between workflows. The initial values in the map are often provided by particular interface activities, e.g. the 'Start from Catalog' activity and then are passed on within the workflow to the following nodes using transitions.

  Example: A workflow "Open Catalog" (A) is started from the Sidebar. The opened catalog may have several other actions mapped, for example (B1...Bn), one of them could be "Edit BO" (B1) which opens an edit for the selected line in the catalog. This edit screen could in turn have other workflows (e.g. change status and save) and so on.

  The workflows can be designed and implemented so that all workflows can share one Shared Values map. The Shared Values are transferred from the interface activities (e.g. “Start from Sidebar”) to the following nodes using the transitions.

  Generally, all activities that open a new GUI window have an input parameter Shared Values and through the Valuemation GUI Model you can transfer the Shared Values to the newly opened GUI element.

  Within a workflow, the Shared Values output on the source node must be connected to the input of the following node using a transition. Then, you can decide whether you want to pass on the same Shared Values you received on the node to its output.

  Three are two options:

  • YES - the incoming values are replicated unchanged at the output. The following node may open up a GUI dialog and access the Shared Values to do so.

    Note: The Shared Values are also automatically available to any workflows which may be started from this dialog.

  • NO - the incoming 'Shared Values' are not passed to the output node. In this case a new Shared Value map is created at the output of the node, filled with new values from the current GUI dialog.

  Example: The workflow is intended to edit a Person BO to change the ID of its CostCenter. Subsequently the user may wish to reallocate the systems belonging to the person to his new cost-center. The task can be divided into two separate, versatile and compatible workflows. One workflow carries out the Edit Person and the other performs the 'Mass move' operation to reallocate the systems.

  After running the first workflow, the new department has already been set. But the second workflow still needs the ID of the original CostCenter in order to carry out the MassMove. This is where the Shared Values are used. The map will store the ID of the original cost-center under a special key and will keep it and transfer it between two separate workflows.

  The activities 'Get from Hash Map' and 'Put In Hash Map' are the main activities used to read / write values to a given Shared Value area. Many other activities also access the Shared Values area (e.g. Choose a BO from a Catalog, Open BO Browser...). Shared values can be also read or modified in the workflow script using 'sharedValues.get(key)' and 'sharedValues.put(key, value)' methods.

• In

  The user input. It is mainly used in scripts where it creates a variable. For the other activities, the input value has no special meaning. It can be used to pass values via this node or for the implementation of the time dependency. See also 'User Names' above on this page.

• Out

  The user output. It is mainly used in scripts to provide the script results using _output.put("parameter", value) function to the activity output. For the other activities, the output value has no special meaning. It can be used to pass values through the node or to implement the time dependency. See also 'User Names' above on this page.

• Return Codes

  Generally, the progress of a workflow to the next step is dependent on receiving some input data. Sometimes a part of a workflow is implemented in such a way that, at least for a specific period of time, no data is returned by the given activity - but information about its result is still required.

  A return code, which can be set as an optional parameter for many activities, can be used in such a case. Return codes can be used to decide whether a user has closed a Catalog with the intention to continue working on the current task in the following session, or that he wants to finish it and progress to the next stage. This information can be passed through the return codes from the dialog to the calling workflow, which then handles this information accordingly. The typical return codes are 'close' and 'finish' for closing Catalogs, suggesting that the user either wants to continue with the current task, or to terminate it. See also the activity 'CatalogViewClose'.

  An unlimited number of customized return codes can be used.

  Example: A workflow provides a user with a list of objects for which a particular task must be carried out. The list includes an action which guides him through this task for each object in the list. The task may take some time to complete, and in some cases he may have to wait for certain pre-conditions to be fulfilled before he can complete the task assigned to him. He does not want to keep the list open all the time (perhaps over a period of days or weeks) but he does want to record his progress. So to close the list he has two options : one which indicates that he is “Finished for now” and will return to the task at a later point, and another which indicates that the task has been “Completed” and any follow-on actions may be initiated. This difference in closing the list can be indicated using different return codes.