Working with Process Definitions

The Modeling perspective visualizes the existing process definitions in the My Process Models panel under model element. You can create, rename and delete process definitions. Each process definition has its property panel wherein you can modify its properties. A typical process definition contains swim lanes, activities and gateways, applications, events, data and sequence flows.

You can perform following operations on any process definition in the Modeling perspective:

• Creating a Process Definition
• Renaming a Process Definition
• Deleting a Process Definition
• Modifying Properties of a Process Definition
• Working with Referenced Process
  • Circular Reference
  • Drag and Drop of a Process without a Process Interface
• Creating Interface Test Process

Creating a Process Definition

Perform the following steps to create a new process definition.

1. Expand the My Process Models panel of the Business Process Modeling perspective
2. Create model using the Create Model option from the My Process Models panel.
3. Right-click the newly created model name and select Create Process. The Process 1 gets created under the model node.

   
   Figure: Creating a Process Definition

Renaming a Process Definition

Perform the following steps to rename the process definition:

1. Under the Models node, right-click the process name and select Rename

   
   Figure: Renaming a Process Definition

2. Specify the new name. The process is renamed.

   
   Figure: Specify New name

Rename can be performed in the My Process Models panel and the property panel of the element.

Deleting a Process Definition

Under the Models node, right-click the process name and select Delete. The process gets deleted.

Figure: Delete Process

Modifying Properties of a Process Definition

To edit properties of a process definition select the process definition under the model node in the outline tree. The properties window is displayed at the top right corner of the swim lane.

General Properties

In the General Properties window of a process definition, you can specify the following properties:

• UUID - A unique identifier ID gets generated as an identifier for client server communication
• ID - An ID generated automatically based on the process name. If element with the same name exists then during ID generation, a numerical suffix gets added to the ID. If the element is renamed, the ID gets regenerated.

  The UUID and ID options are displayed only when you switch to Integrator profile.

• Name - Specify name of the process
• Description - Specify the description
• Default Priority - Specify process priority. By default, it is set to 0. You can set an Integer value for the default priority of the process definition. You can enter any positive value for setting priority as high and any negative value for setting priority as low. Any positive value is treated as high priority and gets converted to 1. Any negative value is treated as low priority and gets converted to -1. The following table explains the priority:
  
  

  Priority Value	Priority Value Converts to
  value > 0 (high priority)	1
  value == 0 (normal priority)	0
  value < 0 (low priority)	-1

Figure: General Properties of Process Definition

Comments

Optionally perform the following steps to specify a comment:

1. Make sure that property panel of the process definition is open
2. Click the Comments icon

   
   Figure: Process Properties -Comments Icon

3. Specify the comment in the text box and click Submit. The newest comment gets displayed at the top of the table.

   
   Figure: Process Properties -Comments

To delete the comment, select the comment and click the Delete icon. The user, who has submitted the comment, only that user can delete the comment. If the other user selects the comment or no comment is selected, the Delete icon remains in disabled state.

Process Interface

Using the process interface, process definition of the provider model can be referenced in the consumer model. For the definition of the process interface, please refer to the chapter Glossary. Glossary in the Stardust Documentation.

To view and modify the process interface properties of a process, perform the following steps:

1. Make sure that the property panel of the process definition is open
2. Click the Process Interface icon

   
   Figure: Process Interface icon

3. Select process interface type from the Type drop-down list. By default, No Process Interfaces option is selected.

   
   Figure: Process Interface - Type

   • No Process Interfaces - By default this option is selected. It means no process interface is defined for the current process definition.
   • Provides Process Interface
   • Implements Process Interface

So there are three valid states concerning declared and implemented process interfaces:

• The process definition neither implements nor declares a process interface
• The process definition provides process interface and it is by default implementer of declared interface.
• The process definition implements a process interface.

Provides Process Interface

This property defines the process interface. A model that wants to expose its process to other consumer model should choose this option. When a process interface property of a process definition is set to Provides Process Interface, it can be referenced from the consumer model. When you select the Provides Process Interface, the following options are displayed:

Figure: Provides Process Interface

• Web Service - If you select this check box then the process interface is invokable remotely via Web service endpoint. The WSDL gets generated at runtime.
• REST Service - If you select this check box then the process interface is invokable remotely via REST endpoint. The WADL gets generated at runtime. For more information, please refer to the chapter Process Interface - External Invocation Mechanism Process Interface - External Invocation Mechanism of the Programming Guide. Programming Guide in the Stardust Documentation.
• Add Parameters -Click the Add icon to specify the process interface parameters. Formal parameters can be defined only for the data from the current model.

  
  Figure: Add Parameters

• Enter the following data settings for the parameter:
  • Name - Specify the name of the formal parameter
  • Direction - The list displays following options:
    • IN - for read access
    • OUT - for write access
    • INOUT - for read and write access
  • Data Type - Select data from the drop-down list. You can select one of the following data types:
    • Primitive - specify the Primitive Type of the data.
      

      Note
      Primitive Enumeration types are not supported as formal parameters in case of SOAP and REST external process invocation. Use a structured data type embedding the required Enumeration type instead.

    • Structured Data - specify the Structured Type of the data. It also lists structured types from other models.
    • Document - specify the Document Type of the data. It also lists structured types from other models.
  • Data - Select data from the drop-down list.
  For details on these data type and data settings refer to section Data Properties of chapter Specifying Data.

Implements Process Interface

A model that wants to provide an alternate implementation of its process definition should opt for Implements Process Interface option. It provides an implementation for a process interface defined in a provider model file.

When you select the Implement Process Interface option, the processes available for implementation are listed.

Figure: Process Properties - Implements Process Interface

When you select the process to be implemented, its exposed parameters are listed under process interface. Note that only Data parameter is editable. This Data field is populated only when you drag and drop the structured type from the Provider model in the Consumer model. Or when you create a data of the same Type and reference it in the Consumer model.

Data Path

If defined as descriptors, data paths can be also used to visualize process data in the Stardust Portals. Note that only data paths defined as descriptors are visible in the Stardust Portals. Perform the following steps to modify the Data Path properties:

1. Click the Data Path icon

   
   Figure: Process Properties - Data Path Icon

2. Click the Add icon to add a new data path

   
   Figure: Process Properties - Data Path

3. ID - ID is generated based on the specified name for data path. This field is displayed only when you switch to Integrator profile.
4. Name - Specify name for the data path
5. Direction - Select In, Out or InOut direction from the drop-down list
6. Descriptor - Select this check box to define a descriptor for a process definition.
7. Key Descriptor - Select this check box to define a key descriptor for a process definition. For more information, please refer to the chapter Working with Data Paths Working with Data Paths of the Modeling Guide. Modeling Guide in the Stardust Documentation.
8. Data - Select data from the drop-down list. It displays data elements from the current model only.
9. Path - Specify data path, if applicable. This field has auto-completion facility. You can choose the appropriate option. For the nested structure types, the hierarchy should be delineated with a "dot", as shown in the following screenshots.

   

Providing the total count of attached documents as descriptor

You have the option to provide the total count of attached documents for a process definition as descriptor. To make the number of attached documents available as descriptor perform the following steps:

1. Make sure the Process Supports Attachments option is selected for your process. Please refer to section Process Attachments for details on how to support process attachments in your process.

   

2. Add a new In-data path as described above
3. Mark the data path as descriptor
4. In the Data drop-down list select Process Attachments

   

5. Add documentCount in the Path field

   

Now the count of process attachments is displayed for processes in the Descriptor columns in your Portal process tables, e.g.:

Figure: Document count displayed as descriptors in a Process Table

Display

Perform the following steps to modify the Display properties:

1. Click the Display icon

   
   Figure: Process Properties- Display Icon

2. Select a check box Is Auxiliary Process to mark a process as auxiliary from a business perspective. Thus, non-business relevant process instances can be hidden in the Stardust Portal. This check box is not selected, by default.

   
   Figure: Process - Display

Process Attachments

Perform the following steps to specify if process attachments are supported:

1. Click the Process Attachments icon

   
   Figure: Process Attachments Icon

2. Select the check box Process supports attachments, if the process should support an attachment
3. If the Unique per root process instance check box is selected, all process attachments pertaining to subprocesses access the root process data instead of the scope process data.

   For more information, please refer to the section Unique per root process instance Unique per root process instance of the chapter Working with Process Definition Working with Process Definition of the Modeling Guide. Modeling Guide in the Stardust Documentation.

   
   Figure: Process Attachments

Runtime Behavior

Using this option, you can specify audit trail persistence modes. Perform the following steps to specify the runtime behavior.

1. Click the Runtime Behavior icon

   
   Figure: Runtime Behavior Icon

2. Select the persistence mode from the Persistence drop-down list. You can select following options:
   • Immediate - By default, this option is selected. The process and potentially all its subprocesses should be executed transiently and audit trail data will only be kept in an in-memory cache for the time until the process instance completes. Upon completion of the process hierarchy, all audit trail data is discarded for this process instance and no audit trail will be persisted to the database.
   • Transient - The process and all its subprocesses should be executed transiently and audit trail data is only kept in an in-memory cache for the time until the process instance completes. Upon process completion the data is stored to the audit trail data base asynchronously.
   • Deferred - The audit trail should be persisted to the audit trail database directly and synchronously along with activity thread processing.

   
   Figure: Runtime Behavior - Persistence

Though the default selection is Immediate; as long as you do not change anything, the XPDL does not contain the attribute. Note that you need to select and save the persistence value explicitly to go into the XPDL.

For more information, please refer to the chapter Audit Trail Persistence Audit Trail Persistence of the Concepts Handbook Concepts Handbook in the Stardust Documentation.

Working with Referenced Process

The process can be referenced in another model only when the Provides Process Interface option is set for the process. The referenced process definition becomes the subprocess in the referencing model. Note that the elements referred externally are hidden in the My Process Models panel of the Consumer model.

Drag and drop the process from the referenced model.

Figure: Drag Referenced Process Definition

If the selected subprocess is a referenced process from a provider model then the following execution types are available:

• Synchronous / Separate Data
• Asynchronous / Separate Data
• Synchronous / Shared Data

By default, Synchronous / Separate Data is selected. Note that in these cases invocation at runtime is always done via the process interface. If the selected subprocess is a process from the same model then the subprocess will be invoked directly at runtime as no process interface exists. For more information on execution types, please refer to the chapter Configuring Subprocess Activities Configuring Subprocess Activities of the Modeling Guide. Modeling Guide in the Stardust Documentation.

Runtime Dynamic Binding of Data

To define the dynamic binding, you need to have the referenced process added from the consumer model. Dynamic binding enables you to choose the implementation model at runtime. To enable the dynamic binding, you can mark the subprocess activity that invokes process interface, to be resolved at runtime.

Switch to Integrator profile. Open the properties of the referenced process definition and click on Implementation icon.

Figure: Dynamic Binding

Specify the following details:

• Subprocess - Select the subprocess activity that invokes the process interface which will be resolved at runtime
• Execution - Select execution of the subprocess
• Data - In the Data drop-down list, it is mandatory to provide the target model, implementation model ID or a qualified implementation process Id with type String. The implementation model ID is used to invoke the process definition that implements the selected process interface. Using a qualified implementation process Id allows to have multiple implementing processes in the same model and to select the intended process by the qualified process Id. Note that the ID of the implementing process definition is fetched from the declared implements relationship to the process interface.

Qualified ID should be specified in the following format:

Qualified ID = {Model ID}Implementation Process ID. For example, {Model13}ImplementerProProcess1

For more information, please refer to the section Dynamic Binding of the Multiple Implementations chapter of the Multi Model Audit Trail Setups of the Concepts handbook.

Circular Reference

A model using model elements from another model cannot be referenced by the other model. For example, if model B is referring elements of model A then model A cannot reference the elements of model B. Thus, circular references are not allowed between models. An error is displayed if you try to establish such a relationship between models.

Figure: Circular Reference Error

For more information, please refer to the chapter Using Elements from Other Process Models Using Elements from Other Process Models of the Multi-model Audit Trail Setups . Multi-model Audit Trail Setups in the Stardust Documentation.

Drag and Drop of a Process without a Process Interface

Processes that do not have process interface defined cannot be dragged and dropped across the models. If you try to drag and drop the process for which the process interface is not defined then the following message is displayed in the process diagram message area and the process does not get added to the process diagram canvas:

Figure: Drag and Drop Process - No Process Interface

For more information, please refer to the section Dragging and Dropping of Elements of the chapter Swim Lanes Usage.

Creating Interface Test Process

For more information on Create Interface Test Process option, please refer to the section Create Interface Test Process of the Specifying Applications chapter.