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.
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
.
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, the following properties
are available:
Figure: Element Name - Composite Type
Figure: Type
Figure: Structured Type - Cardinality
minOccurs is not enforced, and therefore Zero or One
and Exactly One are equivalent.
Figure: Structured Type - Element
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 |
| 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:
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 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:

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.
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
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 {
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:

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:

Figure: Large entry field with blue text
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 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:

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 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.
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.
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
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.
/schemas/mySchema.xsd in the XPDL file,
then in the root folder of the
Document Repository View
in the Administration Perspective of the
Stardust Portal,
create a folder named schemas, then upload mySchema.xsd
to the newly created folder.
/mySchema.xsd in XPDL file then directly upload mySchema.xsd to
the root of the document repository. Alternatively, make a jar containing mySchema.xsd and add
the jar to the model classpath.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:/".
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 |
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:
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.