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 Stardust Documentation. You can define two types of structured types in the Web-based modeling:
This chapter covers:
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
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.
To delete structured type, right-click the structured type created under Structured Types node and select Delete.
Figure: Deleting Structured Types
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
The UUID and ID options are displayed only when you switch to Integrator profile.
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 Stardust Documentation.
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.
Select Enumeration to create enumeration types. It means that data object is 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, you need to specify following properties:
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 <New> cell.

Figure: Enumeration Values
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.

Figure: Defining Enumeration types via Java Binding
By default, Composite is selected as type. The
icon
represents composite type data in the model tree. If this type is selected, you need to specify the following properties:
to add elements for structured type.
Figure: Element Name - Composite Type
Figure: Type
Figure: Structured Type - Cardinality

Figure: Structured Type - Element
To delete the specified element, select the element and click the Delete
icon.
Also, to change the order of the elements, click the Move Up and Move Down
icons.
Figure: Structured Type - Parent
Figure: Parent Structured Type Elements - Top of the table
Figure: Storage Properties
Figure: UI 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.
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 |
| 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:
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:

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:

Figure: The customized label is displayed in the manual activity
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 Business Process Modeler. 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:

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.

Figure: Internationalized Label
This property determines, if the description of the structured data should be displayed or not.
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.
If you set this property to Yes, the activity cannot be completed until you specify a value for that field.
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.

Figure: Entry field with red color
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 {
font-family: Geneva, Arial, Helvetica, sans-serif;
font-size: 13px;
color: blue0;
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. font-weight and set it in CSS Style. In the following example, we like to have a bold font weight in the entry field:

Figure: Setting style and style class
In a manual activity having a data of the specified structured data type as in/output, entered text in this entry field is displayed in bold now:

Figure: Entry field text displayed in bold
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:

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:

Figure: Prefix and Suffix displayed in the Portal
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 Business Process Modeler. 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:

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.

Figure: Internationalized prefix and suffix displayed in the Portal
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.
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.
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.
You also have the option to create new Structured Types by importing XSD files. To import type declarations, perform the following operations:
Figure: Structured Type - Import Type Declarations
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.
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.
You can import XSDs in Web-based modeler 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.
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 Online Documentation - Programming Guide for details.
You can import XSDs with an <include> tag. The following example XSD Employee.xsd contains an <include> tag for the Educational_Qualification.xsd and Order.xsd.
<?xml version="1.0" encoding="utf-8" ?>
<!--Created with Liquid XML 2013 Designer Edition (Trial) 11.0.8.4549 (http://www.liquid-technologies.com)-->
<xs:schema xmlns:ns0="http://www.infinity.com/bpm/model/Order"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="http://localhost:8080/SalesProject/Educational_Qualification.xsd" />
<xs:import schemaLocation="http://localhost:8080/SalesProject/Order.xsd"
namespace="http://www.infinity.com/bpm/model/Order" />
<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 files are offered to be imported as well.
Figure: Import Type Declaration - XSD with <include> Tag
If you upload a model created in Eclipse-based modeler referring local XSD file in Web-based modeler; then the following approach ensures that models loaded in the Web modeler 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.
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:/".
Following table helps you to map the primitive types defined in web-based modeler with Eclipse-based modeler.
| Web-based Modeler | Eclipse-based Modeler |
|---|---|
| Text | xsd:string |
| Boolean (True, False) | xsd:boolean |
| Long Number (e. g. 18,765, 64 bit) | xsd:long |
| Number (e. g. 18,765, 32 bit) | xsd:int |
| Date (e. g. 14.04.2013) | xsd:date |
| 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 |
| Money Amount (e. g. 4500, 600.42) | xsd:decimal |
| Date and Time (14/04/2013, 6:24 PM) | xsd:dateTime |
If the Public Visibility property is selected for the structured type in the referenced model then you can refer the structured type in another model. To refer the structure type:
Drag and drop the structured type to referencing process from the Structured Type node of the referenced model. When you drag and drop the structure type, the structure data referring that structured type gets created in the Data node of model under the My Process Models panel.
Figure: Drag Referenced Structured Type
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.
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 Stardust portal. Perform the following steps, to work with Parent structure type:
Figure: Composite Structured Type - Employee
Figure: Composite Structured Type - Person
Figure: Parent Structure - Person
Figure: Person Inherited in Employee
Figure: Sample Model
Figure: User Interface for Inherited Elements
If a duplicate field name is added at the time of a structure type declaration, the following validations are displayed:
Figure: Duplicate Field Name - Validation
Figure: Model Properties - Deployment - Validation
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.