Working with Structured Types

You can define structured types in the Web-based modeling. For more information on Structured Types, refer to the Structured Data Types Structured Data Types chapter of the Modeling Guide. Modeling Guide in the Infinity Process Platform Documentation. You can define two types of structured types in the Web-based modeling:

This chapter covers:

Creating Structured Types

To create structured types, in the My Process Models panel, right-click the Structured Types node and select Create Data Type.


Figure: Creating Structured Types

Renaming a Structured Type

To rename structured type, right-click the structured type created under Structured Types node and select Rename.


Figure: Renaming Structured Types

Rename can be performed in the My Process Models panel, property panel of the element, and by double-clicking element in the Process Diagram canvas.

Deleting a Structured Type

To delete structured type, right-click the structured type created under Structured Types node and select Delete.


Figure: Deleting Structured Types

Defining Structured Type Properties

To define the structured type, click the structured type name under the Structured Type node in the My Process Models panel. The properties page of the structured type opens in the right panel.


Figure: Structured Type - Definition

Setting general Properties

Defining the Structured Type

To define the structured type to be used, open the Configuration tab in the properties view. You can define one of the following types:

For more information on structured types, please refer to the chapter Structured Data Types Structured Data Types of the Modeling Guide. Modeling Guide in the Infinity Process Platform Documentation.

Adding Comments

To add comments to your structured data type, click the Comments tab. Add a comment in the text box and click Submit. The newest comment gets displayed at the top of the table.


Figure: Structured Type - 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.

Defining Enumeration Types

Select Enumeration to create enumeration types.


Figure: Select Enumeration Type

An enumeration is a data object of type string and accepts values from the list of values. The icon represents an Enumeration type data in the model tree. If you select Enumeration from the drop-down list, the following properties are available:


Figure: Enumeration Properties

Optionally you can enter a Minimum Length and a Maximum Length for the enumeration field. The maximum length should be greater than minimum length.

To add values for the Enumeration type, click the Add icon . Specify the value in the entry field.


Figure: Enumeration Values

To delete an entry, click the Delete icon .

Binding to Java

You can retrieve enumeration types from a Java class that defines these types. If you select the Bind to Java, option you can enter the fully-qualified name of such a Java class. The enumeration values defined by this class are listed in the Values section.

For example, the following Java enumeration is used to determine an enumeration for currency:

package org.example.enumeration;

/**
 * Determines currency enumeration values
 */
public enum Currency {
      EUR, USD, GBP, INR, CHF, AUD
};

If you select Bind to Java and enter the fully-qualified name of this class, the defined values are listed in the Values section for the enumeration type definition.

Bind to Java
Figure: Defining Enumeration types via Java Binding

Defining Composite Types

By default, Composite is selected as type. The Composite Type icon represents composite type data in the model tree. If this type is selected, the following properties are available:

Storage Properties

You can set the values for Indexed and Persistent in the Property column. By default, all data fields in the structure are persisted and indexed.

Defining UI Field Properties

You can define the following UI field level properties for a structured data:

Property Value
Label any string as label
Label Key any string used as key for the label in the properties bundle
Show Description Yes / No
Read-only Yes / No
Show Thousands Separator Yes / No
Mandatory Yes / No
CSS Style CSS style with value (<css style>:<value>)
CSS Style Class the class name from the stylesheet file
Prefix I18N Key any string used as key for the prefix in the properties bundle
Prefix any string as prefix
Suffix I18N Key any string used as key for the suffix in the properties bundle
Suffix any string as suffix
String Input Type Text Input or Text Area
Text Area Rows number of rows to be displayed in the entry field
Text Area Columns number of columns to be displayed in the entry field
Boolean Read-only Input Type Checkbox or Text Output

Refer to the following sections for details on these properties:

Label

The specified text entered as String is displayed as label for the according entry field in a manual activity, which has a data of the specified structured data type as in/output. Note that if property Label Key is provided, Label is overridden.

For example, enter Customername as value for the Label property for a structured type entry name, as shown below:

Label Property
Figure: Setting a Label property

In a manual activity having a data of this structured data type as in and out data mapping, the label for the name property is displayed as Customername:

Example Label
Figure: The customized label is displayed in the manual activity

Label Key

This property specifies a key, which is set in the according language bundle properties file in the Eclipse modeler. Note that model element internationalization is not supported yet in the Modeling perspective. This key has to be set in the Eclipse modeler and the according model needs to be imported.

The format for this property is <key string> = <specify value>, e.g. <structured type>.<field>.<label>.<key>. The value for the key will be read from the properties file and displayed in the manual activity in the specified language as label for the structured data field.

For example, if you add Person.name.label.key as string for the Label Key as shown in the following screenshot:

Label Key
Figure: Setting a Label Key property

Enter the following in the modeler language bundle properties file in the Eclipse modeler, for this example the German bundle, and save it:

Person.name.label.key=Kundenname

Import the model. If you set the Browser language to German, the label for the name property of this structured type is displayed as Kundenname in a manual activity having this structured data type as in/out data mapping.

Internationalized Label
Figure: Internationalized Label

Show Description

This property determines, if the description of the structured data should be displayed or not.

Read-only

If you select Yes for this property, the field becomes read-only. In case an In-Out data mapping is provided for this field, it gets overridden and the field remains read-only.

Show Thousands Separator

To make large number fields readable, you can select this check box to add grouping separator (comma) to a structured data field.


Figure: Show Thousands Separator

Note that this is supported only for numeric descriptors based on Structured Data.


Figure: Thousands Separator - Structured Types

Mandatory

If you set this property to Yes, the activity cannot be completed until you specify a value for that field.

CSS Style

This property specifies a specific style for the field. Enter the style and a value in the following format: <css style>:<value>. For example, if you specify Color:Red for a field, the value for this field is taken in red color.

Entry field with red color
Figure: Entry field with red color

CSS Style Class

If you have a stylesheet file you use in the Portal, you can reference a specific class in this stylesheet that you like to use in your entry field. The stylesheet file must be included in the skin selected for the Portal in the Configuration Panel. For details on how to create and use custom skins refer to chapter Creating and Using Custom Skins.

For example if your stylesheet contains the following class:

.democlass {
    color: blue;
    font-style: normal;
    line-height: 18px;
    font-weight: normal;
}

you can enter the value democlass for the property CSS Style Class to be used as reference. Then you can use a value from this class, e.g. line-height and set it in CSS Style. In the following example, we like to have a larger line height in the entry field:

Style and Style Class
Figure: Setting style and style class

In a manual activity having a data of the specified structured data type as in/output, the entry field height is larger and the entered text is displayed in blue color:

Style Class Example
Figure: Large entry field with blue text

Prefix and Suffix

The specified text entered as String for the properties Prefix and Suffix is displayed as prefix and suffix respectively in a manual activity for the specified field. Note that if property Prefix I18N Key or Suffix I18N Key is provided, Prefix or Suffix will be overridden.

For example, enter Department A as value for the Prefix property and Section 1 as value for the Suffix property for a structured type entry name, as shown below:

Prefix and Suffix
Figure: Enter a string for Prefix and Suffix

In a manual activity, having a data as in/output of the according structured data type, the name field has prefix Department A and suffix Section 1:

Prefix and Suffix Example
Figure: Prefix and Suffix displayed in the Portal

Prefix and Suffix I18N Keys

The I18N key properties for prefix and suffix specify keys, which are set in the according language bundle properties file in the Eclipse modeler. Note that model element internationalization is not supported yet in the Modeling perspective. These keys have to be set in the Eclipse modeler and the according model needs to be imported.

The format is <key string> = <specify value>, e.g. <structured type>.<field>.<prefix>. The value for the keys will be read from the properties file and displayed in a manual activity in the specified language as prefix and suffix for the structured data field.

For example, add Person.name.prefix as string for the Prefix I18N Key and Person.name.suffix as string for the Suffix I18N Key as shown in the following screenshot:

Setting i18n prefix and suffix keys
Figure: Setting I18N prefix and suffix keys

Add the following keys to the modeler language bundle properties file in the Eclipse modeler, in this example the German bundle, and save it:

Person.name.prefix = Abteilung A
Person.name.suffix = Sektion 1

Import the model. If you set the Browser language to German, the prefix for the name property of this structured type is displayed as Abteilung A, the suffix as Sektion 1 in a manual activity having this structured data type as input data mapping.

I18n Prefix and Suffix Example
Figure: Internationalized prefix and suffix displayed in the Portal

String Input Type

If Text Input is selected for the String Input Type property, the following fields Text Area Rows and Text Area Columns become invalid. If Text Area is selected, you can specify more characters. For example, you can specify the complete address of home and office.

Text Area Rows and Columns

The Text Area Columns and Text Area Rows properties specify the number of rows and columns to be displayed. If property String Input Type is set to Text Area, only the specified number of rows and columns are displayed.

Boolean Readonly Input Type

The type of the field should be xsd:boolean. If Checkbox is selected, a checkbox appears next the field.

If Text Output is selected, the values True or False are displayed. For Text Output, you need to provide an Out-data mapping for the first activity and an In-data mapping should be provided to the following activity.

Importing Type Declarations

You also have the option to create new Structured Types by importing XSD files. To import type declarations, perform the following operations:

  1. In the My Process Models panel, right-click the Structured Types node and select Import Type Declarations.


    Figure: Structured Type - Import Type Declarations

  2. In the XSD Data Structure Import dialog, specify the URL and click Load. Note that URI only is supported for import of type declaration.


    Figure: XSD Data Structure Import

    Note that you may need to do server-side configuration for the proxy server and port to load the schema from specified URL. Also, if the specified URL is not valid then the validation message gets displayed.

  3. Select the type declaration from imported schema and click Import


    Figure: Import - Type Declaration

The imported type declaration gets displayed under the Structured Types node of the model.


Figure: Imported Type Declaration

The imported type declaration is represented using this icon. Note that imported types are not displayed for local structured data.

Note
In case you select an imported referenced type as nested type for an element in other structured data type, the name and type of the element changes automatically to the name and type of the imported xsd type.

XSD Inheritance

You can import XSDs in the Modeling perspective which supports inheritance. Using inheritance, it is possible to create a complex type and then create an element that extends it by adding elements or attributes. The following example has a complex type, fullpersoninfo, that derives from another complex type, personinfo, by extending the inherited type personinfo with three additional elements (address, city and country):

<xs:element name="employee" type="fullpersoninfo"/>

<xs:complexType name="personinfo">
   <xs:sequence>
     <xs:element name="firstname" type="xs:string"/>
     <xs:element name="lastname" type="xs:string"/>
   </xs:sequence>
 </xs:complexType>

<xs:complexType name="fullpersoninfo">
   <xs:complexContent>
     <xs:extension base="personinfo">
       <xs:sequence>
         <xs:element name="address" type="xs:string"/>
         <xs:element name="city" type="xs:string"/>
         <xs:element name="country" type="xs:string"/>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
 </xs:complexType>

When imported, the employee element must contain, in sequence, the following elements: firstname, lastname, address, city, and country.

Using Cross-Model Type Declarations with custom Clients

If you use cross-model type declarations with a custom client, you must ensure that the client side schema is properly resolved. This can be achieved by installing a custom schema resolver in the corresponding model before the type declaration is obtained. Please refer to chapter Using Cross-Model Type Declarations with custom Clients in the Programming Guide Using Cross-Model Type Declarations with custom Clients in the Documentation - Programming Guide for details.

Importing XSDs with <include> Tag

You can import XSDs with an <include> tag. The following example XSD Employee.xsd contains an <include> tag for Person.xsd.

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:include schemaLocation="Person.xsd" />
   <xs:complexType name="EMP_Personal_Info">
      <xs:sequence>
         <xs:element name="Name" type="xs:string" />
         <xs:element name="ID" type="xs:long" />
      </xs:sequence>
   </xs:complexType>
   <xs:element name="Employee" type="EMP_Personal_Info" />
</xs:schema>

If you import the Employee.xsd via the Import Type Declaration dialog, the included xsd file is offered to be imported as well.


Figure: Import Type Declaration - XSD with <include> Tag

Working with External XSDs

If you upload a model created in the Eclipse-based modeler referring a local XSD file in the Modeling perspective, the following approach ensures that models loaded in the Modeling perspective are able to locate the referenced schemas.

Note that these external structured types are read-only.

If an external schema could not be resolved then the warning message is displayed in the structured data type property panel.


Figure: External Schema Reference - Message

The resources should be at classpath to get the model deployed successfully having external schema references.

Relative URIs

The URI indicates the modeler where an external schema can be found, the location of it and the location can be absolute (a specific file in the file system or some remote location) or relative (relative paths may be safely used when the external schema is located in the classpath).

For Web-based modeling, relative URIs are resolved first against the classpath as if it is the absolute URI classpath:/<relative URI>; and if no resource is found then it searches in the repository as if it is the absolute URI jcr:/<relative URI>. Other accepted URIs are "file:/", "http:/", "https:/".

Mapping Primitive Types created in the Modeling Perspective to the Eclipse-based Modeler

The following table gives an overview on how primitive types defined in the Modeling perspective are mapped to appropriate types in the Eclipse-based modeler.

Modeling Perspective Eclipse-based Modeler
Boolean (True, False) xsd:boolean
Date (e. g. 14.04.2013) xsd:date
Date and Time (14/04/2013, 06:24 PM) xsd:dateTime
Long Number (e. g. 18,765, 64 bit) xsd:long
Money Amount (e. g. 4500, 600.42) xsd:decimal
Number (e. g. 18,765, 32 bit) xsd:int
Number (e. g. 18,765, 16 bit) xsd:short
Number (e. g. 112, 8 bit) xsd:byte
Scientific (e. g. 3.141592, high precision) xsd:double
Scientific (e. g. 3.141592, regular precision) xsd:float
Text xsd:string

Working with Referenced Structured Type

If the Public Visibility property is selected for a structured type in a referenced model, you can refer the structured type from another model. To refer the structured type do the following:

You can also select the structured data from the Structured Type drop-down list of other models to refer it.

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

Example of Parent Structure Type

In this example, we are creating two Composite structured types, named Employee and Person. The Person structured type is inherited in Employee. To inherit the Person structured type, you need to define it as Parent structure type. Then, we will create a model to see the UI generated with these structured types in the Infinity Process Platform portal. Perform the following steps, to work with Parent structure type:

Validations for Structured Types

If a duplicate field name is added at the time of a structure type declaration, the following validations are displayed:

If a child SDT extends a parent SDT, and the parent SDT is deleted. The validation is displayed in the structure type view:


Figure: Structure Type View - Validation

The following validation is displayed in the Problems tab of the model properties view, as well:


Figure: Model Properties - Problems Tab - Validation

If the referenced SDT is deleted then a validation is displayed at the time of model deployment.


Figure: Model Properties - Deployment - Validation

You should set it to None or select any other structure type from the drop-down list.