Understanding the Data Dictionary building block assets

The data dictionary is a catalog of data elements, and their descriptions, used in a business domain using a business vocabulary. The data dictionary also contains metadata for managing the data model to provide descriptions of the data structures and their associated attributes. Typically, business users do not require knowledge of metadata representations like XSD (xml schema), FML (Adobe application modeling language), Java classes, and ActionScript classes, used by developers. However, they usually require access to these data structures and attributes to build solutions. The Data Dictionary building block provides an independent representation of metadata and back-end integration. Business users, with no knowledge of back-end system integration, can use this building block to create and use models at a solution level. Within LiveCycle, business users are able to express conditions or use data in the solution's workflows using the data dictionary.

Tools

Developing a Solution Accelerator that uses a data dictionary typically involves the use of the following tools:

  1. Data Dictionary Browser. The user interface that enables browsing a data dictionary and its elements.

  2. Data Dictionary Editor. The user interface that allows creation and maintenance of the data dictionary that is shipped with this building block. It is accessed through the Manage Assets page in your portal:

    • Enables import of domain-specific XSD schema to create a data dictionary.

    • Allows addition/deletion of data dictionary elements (DDEs) over/from a data dictionary

    • Allows association of attributes at data dictionary level.

    • Allows association of attributes at DDE level.

    • Allows exporting of a data dictionary into annotated FML.

    • Allows importing of an annotated FML to create a data dictionary.

    • Allows creation of sample data xml for a data dictionary. The sample xml can be used to enable the data dictionary instance-dependent use cases, quickly, without having back-end support in place.

  3. Java Development Tools:

    • IDE for creating Java/Spring projects

    • ANT build tools

  4. LiveCycle Tools

    • Adobe® LiveCycle® Designer 9

    • Flash® Builder™

For additional information about the Data Dictionary building block services, see these resources:

Data Dictionary Browser

The Data Dictionary Browser presents elements in a tree structure. The browser allows selection of DDEs so they can be referenced.

View full size graphic
Data Dictionary Browser

Data Dictionary Editor

The Data Dictionary Editor is used for creating and managing data dictionaries. A middleware developer can create, modify, and delete metadata properties for both the data dictionary and its elements using the Data Dictionary Editor. The Data Dictionary Editor enforces validations while creating or updating a data dictionary. For more information on the rules for creating DDEs for a valid schema, see Data dictionary elements .

View full size graphic
Data Dictionary Editor

The Data Dictionary Editor allows business process owners to create data dictionaries by importing them from a valid XML schema or FML model. Business process owners can also export their data dictionaries to FML or generate a sample xml data from the Data Dictionary Editor.

If the middleware developer attempts to import a schema with multiple top-level elements, the Data Dictionary Editor prompts for a single top-level element. The developer selects one of the top elements for use in creating a data dictionary tree. The data dictionary represents a cohesive instance of data for a given context, rather than a set of disjointed data. An XSD with a forest of elements represents multiple trees of elements - with each tree being an unrelated data set. A data dictionary is created over one such tree. It does not allow import of annotated FMLs with multiple top-level entities. Both the name, and element type for a data dictionary/DDE are required parameters and must be specified. A parent DDE (composite) can't have two children with the same name.

Data Dictionary Editor validations

The Data Dictionary Editor enforces following validations when creating or updating a data dictionary.

  • Only composite type is allowed as Top-level Element in a data dictionary.

  • Composite and Collection elements are not allowed at leaf level. Only Primitive (String, Date, Number, Boolean) elements are allowed at leaf level. This validation ensures that there is no composite and collection element without a child DDE.

  • While importing XSD to create a data dictionary, the Data Dictionary Editor Prompts for a top-level element, if multiple exist, to create the data dictionary.

  • Does not allow import of annotated FMLs with multiple top-level entities.

  • The name and element type for a data dictionary/DDE are required parameters.

  • A parent DDE (composite) can't have two children with the same name

  • Ensures a DDE is marked computed, only if it is not a required parameter. A required element cannot be computed and a computed element cannot be required. Also, Collection and Composite Element cannot be computed elements.

  • Ensures a DDE is marked required, only when it is not computed. It also ensures that it is not the "collectionElement" denoting the type of Collection (that is the only children of a collection Element).

  • Empty keys or Duplicate keys are not allowed in extendedProperties for a data dictionary or DDE.

  • Do not use the colon(:) or vertical bar(|) characters within the key or value of an extended property. If you do, the key can be lost or split into multiple keys. There is no validation for the use of these prohibited characters.

Validations that are applied at the Data Dictionary Level
  • The Data Dictionary name must not be null.

  • The Data Dictionary name may only contain alphanumeric characters.

  • The child element list in the Data Dictionary must not be null or empty.

  • The Data Dictionary must not contain more than one top level Data Dictionary Element.

  • Only composite type is allowed as Top-level Element in a Data Dictionary.

Validations that are applied at the Data Dictionary Element Level
  • All DDE names must not be null.

  • All DDEs must not have a null Element Type.

  • All DDE display names must not be null.

  • All DDE display names must be unique.

  • All DDE names may only contain alphanumeric characters and “_”.

  • All DDE display names may only contain alphanumeric characters and “_”.

  • Composite and Collection elements are not allowed at leaf level. Only Primitive (String, Date, Number, Boolean) elements are allowed at leaf level. This validation ensures that there is no composite and collection element without a child DDE.

  • A composite parent DDE must not have two child elements with the same name.

  • The ENUM subtype may only be used for String and Number elements.

  • Collection and Composite elements cannot be computed.

  • A DDE cannot be both computed and required.

  • Computed DDEs must contain a valid non-null epression.

  • Computed DDEs must not have XML binding.

  • Collection DDEs that denote its type must not be computed or required.

  • DDEs of subtype ENUM must not contain null or empty value sets.

  • The XML binding of a collection DDE must not map to an attribute.

  • The XML binding syntax must be valid, such as, only one @ appears, the @ should only be followed by an attribute name, and so on.

Data Dictionary Services

The Data Dictionary building block services are exposed as spring beans. Following is the list of beans that are provided in Data Dictionary building block:

Name

Description

DataDictonaryRegistryService

Provides operations creating, retrieving, updating and deleting (CRUD operations) for a data dictionary.

DataDictionaryUtilService

Provides data dictionary utility functions to:

  • Import an XSD to create a data dictionary.

  • Import/export of a data dictionary as annotated FML.

  • Create a data dictionary object from XSD/FML. The data dictionary object can then be persisted through the APIs in the DataDictionaryRegistryService.

  • Create sample xml data.

Default endpoints

The Data Dictionary building block APIs are exposed by default over Flex remoting. The APIs are not exposed for java clients. The solution integrator can expose the spring beans over their chosen endpoints with desired level of security. The configuration is property of a solution and not of the building block.

Dependence of the Data Dictionary building block on Expression Evaluator Service (EXM)

The Expression evaluator (EXM) service is exposed as a building block. The Data Dictionary building block is dependent on the EXM, which is a pluggable component. The Expression evaluator supports JSP EL evaluation. The expression evaluator service is used for evaluating computed DDEs for the data dictionary. The following points detail the DDE evaluation capabilities that the Data Dictionary building block supports using the EXM.

  1. A DDE can be marked as Computed and the corresponding JSP EL expression can be provided for it through the Data Dictionary Editor user interface.

  2. The computing expression for a DDE can be based on the values of other DDEs. For example, a DDE with name 'fullName' can bear an expression - ${firstName}$ {lastName} which evaluates full name as concatenation of first and last name.

  3. The Data Dictionary building block does not support nesting of computed expressions. An operand in the expression cannot be another computed expression. The computed DDE evaluation is done on the server side when a DDI is being created.

  4. The computed DDEs are created as non-Required, which means null values are permitted in a DDI.

Security authentication and authorization

No security is configured by default for the Data Dictionary building block service operations. The configuration is left to the system integrator to expose the Data Dictionary APIs at desired level of security.

Data Dictionary run time workflow

The Data Dictionary run time is responsible for returning the data dictionary instances (DDI) corresponding to a data dictionary. The Data Dictionary run time supports creation of DDI from Input XML Data (IXD) only. The solution has an initiating input XML data file that is used to run off its processes. For example, a letter generation process that is triggered with an input XML file containing all the relevant details. The input XML data must confirm to the schema of the XSD from which a data dictionary was created.

If a data dictionary was created manually, there would not have been any default XSD schema. When a data dictionary is created from an XSD schema, the import was modified, it's possible for its structure to decouple with the starting XSD schema. To prevent these errors, the Data Dictionary building block provides a tool to generate a sample XML corresponding to the data dictionary. The driving system ensures that IXD is provided to the system in the format consistent with the sample XML. The Data Dictionary run time creates a DDI out of the input XML based on a given data dictionarydata dictionary reference. The DDI can then be used to fill in the values in the application. The DDI is a read only artifact, which means there is no support of writing back data dictionary instances in the system. However, a data dictionary instance can be serialized and passed around in the workflows.

End-to-end flow definition

The following diagram details the end-to-end data dictionary definition. It includes the integration process including the personas involved, tools used, metadata storage, and its access at run time:

View full size graphic
Data dictionary definition
  1. The Business Process Owner can use the Data Dictionary Editor to create a data dictionary manually. For information on creating the data dictionary using the Data Dictionary Editor, see Creating a data dictionary .

  2. The Business Process Owner can also use the Data Dictionary Editor to create data dictionary by importing a schema.

  3. On saving the data dictionary, the data dictionary metadata definition gets stored in the back end ie in the asset manager.

  4. The business process owner can export the data dictionary using the Data Dictionary Editor, in form of an annotated FML model. This annotated model can then be imported to create a data dictionary.

  5. A LiveCycle developer can use the domain XSD to create both the data dictionary and the artifacts such as the forms for the application. Designer can be used for importing an XSD and creating relevant forms from it.

  6. The Solution Developer creates the solution in terms of artifacts, such as forms required by the application, corresponding Java classes, flex components, and so on.

  7. The Solution Developer assembles them into a deployable archive (for example, a solution ear/war or just a set of solution beans). The solution is then deployed. The solution can be tested with sample data dictionary XML generation capability exposed through the Data Dictionary Editor.

  8. The deployed customer solution accesses both the Data Dictionary metadata and Data Dictionary run time to accomplish its flows. For example, a document composer application accesses a letter data dictionary to render the required fields.

  9. The Data Dictionary run time accesses the Data Dictionary metadata to create the Data Dictionary Instances (DDI). For more information on the Data Dictionary run time see Data Dictionary run time workflow .

  10. The Data Dictionary run time does not integrate directly with back-end legacy systems.

Samples

The following details sample models and code samples which show implementation details for the Data Dictionary building block.

Mapping Simple (Primitive) Elements

A primitive DDE represents a field or attribute which is atomic in nature. Primitive data dictionary elements defined outside the scope of a complex type (composite DDE) or a repeating element (collection DDE) can be stored in any location within the XML Schema. The location of the data corresponding to a primitive DDE is not dependent on the mapping of its parent DDE. Primitive DDE uses the mapping information from the XML Binding field to determine its value and the mappings translate into one of the following:

  • an attribute

  • an element

  • a text context

  • nothing (an ignored DDE)

The following example shows a simple schema.

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:element name='age' type='integer'/> 
    <xs:element name='price' type='decimal'/> 
</xs:schema> 

Mapping Composite Elements

Allowing absolute mapping for child elements of a Composite DDE provides more flexibility in terms of Xpath Binding. Mapping a composite DDE to a particular complex type element in XML schema limits the scope of binding its child elements.

The following example shows the schema for a note.

<xs:element name="note"> 
    <xs:complexType> 
        <xs:sequence> 
            <xs:element name="to" type="xs:string"/> 
            <xs:element name="from" type="xs:string"/> 
            <xs:element name="heading" type="xs:string"/> 
            <xs:element name="body" type="xs:string"/> 
        </xs:sequence> 
    </xs:complexType> 
</xs:element> 

Mapping Collection Elements

A collection element must be mapped only to another collection element (which has cardinality > 1). The child DDEs of a collection DDE have relative(local) XML Binding with respect to its parent's XML Binding. As the child DDEs of a collection element must have the same cardinality as that of parent, the relative binding is mandated to ensure the cardinality constraint so that the child DDEs don't point to a non repeating XML Schema element. In the example below, the cardinality of "TokenID" must be same as that of "Tokens" which is its parent collection DDE.

The XML Schema below declares an element with the name Tokens and a maxOccurs attribute of “unbounded”. Thus, Tokens is a collection element.

<?xml version="1.0" encoding="utf-8"?> 
<Root> 
  <Tokens> 
    <TokenID>string</TokenID> 
    <TokenText> 
      <TextHeading>string</TextHeading> 
      <TextBody>string</TextBody> 
    </TokenText> 
  </Tokens> 
  <Tokens> 
    <TokenID>string</TokenID> 
    <TokenText> 
      <TextHeading>string</TextHeading> 
      <TextBody>string</TextBody> 
    </TokenText> 
  </Tokens> 
  <Tokens> 
    <TokenID>string</TokenID> 
    <TokenText> 
      <TextHeading>string</TextHeading> 
      <TextBody>string</TextBody> 
    </TokenText> 
  </Tokens> 
</Root> 

Sample Schema that can be imported into the Data Dictionary

The following example shows the schema for a company.

<?xml version="1.0" encoding="utf-8"?> 
<xs:schema xmlns="DCT" targetNamespace="DCT" xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" attributeFormDefault="unqualified"> 
  <xs:element name="Company"> 
    <xs:complexType> 
      <xs:sequence> 
        <xs:element name="Name" type="xs:string"/> 
        <xs:element name="Type" type="xs:anySimpleType"/> 
        <xs:element name="HeadOfficeAddress" type="Address"/> 
        <xs:element name="SalesOfficeAddress" type="Address" minOccurs="0"/> 
        <xs:element name="HeadCount" type="xs:integer"/> 
        <xs:element name="CEO" type="Employee"/> 
        <xs:element name="Workers" type="Employee" maxOccurs="unbounded"/> 
      </xs:sequence> 
    </xs:complexType> 
  </xs:element> 
  <xs:complexType name="Employee"> 
    <xs:complexContent> 
      <xs:extension  base="Person"> 
        <xs:sequence> 
          <xs:element name="CurrAddress" type="Address"/> 
          <xs:element name="DOJ" type="xs:date"/> 
          <xs:element name="Phone" type="xs:integer"/> 
        </xs:sequence> 
      </xs:extension> 
    </xs:complexContent> 
  </xs:complexType> 
  <xs:complexType name="Person"> 
    <xs:sequence> 
      <xs:element name="PersonName" type="Name"/> 
      <xs:element name="DOB" type="xs:dateTime"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="Name"> 
    <xs:sequence> 
      <xs:element name="FirstName" type="xs:string"/> 
      <xs:element name="MiddleName" type="xs:string"/> 
      <xs:element name="LastName" type="xs:string"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="Address"> 
    <xs:sequence> 
      <xs:element name="Street" type="xs:string"/> 
      <xs:element name="City" type="xs:string"/> 
      <xs:element name="State" type="xs:string"/> 
      <xs:element name="Zip" type="xs:string"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:schema>

Sample data model

The following code example details the FML export of a Company data dictionary, the data dictionary specific annotations use the DDS annotation. This example also contains two annotation groups: General and XmlBinding. The description and xpath are two respective annotations which are captured as part of these two annotation groups.

<model xmlns="http://ns.adobe.com/Fiber/1.0"> 
  <annotation name="DDS"> 
    <item name="name">Company</item> 
    <item name="displayName">Company</item> 
    <item name="version">1.0</item> 
    <item name="type">NONSYSTEM</item> 
    <item name="extended_k1">v1</item> 
    <item name="extended_k2">v2</item> 
  </annotation> 
  <annotation name="General"> 
    <item name="description"/> 
  </annotation> 
  <entity name="Company"> 
    <annotation name="DDS"> 
      <item name="setAsTopLevelWithName">Company</item> 
      <item name="displayName">Company</item> 
      <item name="extended_k3">v3</item> 
      <item name="extended_k4">v4</item> 
    </annotation> 
    <annotation name="General"> 
      <item name="description"/> 
    </annotation> 
    <annotation name="XMLBinding"> 
      <item name="xpath">/Company</item> 
    </annotation> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property name="Name" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Name</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Name</item> 
      </annotation> 
    </property> 
    <property name="Type" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Type</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Type</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="HeadOfficeAddress" required="true" type="Address"> 
      <annotation name="DDS"> 
        <item name="displayName">HeadOfficeAddress</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/HeadOfficeAddress</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="SalesOfficeAddress" required="false" type="Address"> 
      <annotation name="DDS"> 
        <item name="displayName">SalesOfficeAddress</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/SalesOfficeAddress</item> 
      </annotation> 
    </property> 
    <property name="HeadCount" required="true" type="double"> 
      <annotation name="DDS"> 
        <item name="displayName">HeadCount</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/HeadCount</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="CEO" required="true" type="Employee"> 
      <annotation name="DDS"> 
        <item name="displayName">CEO</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/CEO</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-many" name="Workers" required="true" type="Employee[]"> 
      <annotation name="DDS"> 
        <item name="displayName">Workers</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Workers</item> 
      </annotation> 
    </property> 
  </entity> 
  <entity name="Address"> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property name="Street" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Street</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Street</item> 
      </annotation> 
    </property> 
    <property name="City" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">City</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/City</item> 
      </annotation> 
    </property> 
    <property name="State" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">State</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/State</item> 
      </annotation> 
    </property> 
    <property name="Zip" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Zip</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Zip</item> 
      </annotation> 
    </property> 
  </entity> 
  <entity name="Employee"> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property cardinality="one-to-one" name="PersonName" required="true" type="Name"> 
      <annotation name="DDS"> 
        <item name="displayName">PersonName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/PersonName</item> 
      </annotation> 
    </property> 
    <property name="DOB" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">DOB</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/DOB</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="CurrAddress" required="true" type="Address"> 
      <annotation name="DDS"> 
        <item name="displayName">CurrAddress</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/CurrAddress</item> 
      </annotation> 
    </property> 
    <property name="DOJ" required="true" type="date"> 
      <annotation name="DDS"> 
        <item name="displayName">DOJ</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/DOJ</item> 
      </annotation> 
    </property> 
    <property name="Phone" required="true" type="double"> 
      <annotation name="DDS"> 
        <item name="displayName">Phone</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Phone</item> 
      </annotation> 
    </property> 
  </entity> 
  <entity name="Name"> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property name="FirstName" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">FirstName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/FirstName</item> 
      </annotation> 
    </property> 
    <property name="MiddleName" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">MiddleName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/MiddleName</item> 
      </annotation> 
    </property> 
    <property name="LastName" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">LastName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/LastName</item> 
      </annotation> 
    </property> 
  </entity> 
</model>

Invoke data dictionary APIs through HTTP

In order to use this sample you will need to add the <dct_root>/client/java/adobe-dct-client.jar to your project's classpath.

The data dictionary services are exposed using Spring Remoting over HTTP and the following configuration is loaded in the application context.

 <bean name="/service/DataDictionaryRegistryService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> 
    <property name="service" ref="lc.dct.dataDictionaryRegistryService" /> 
    <property name="serviceInterface" value="com.adobe.dct.service.DataDictionaryRegistryService" /> 
    </bean> 
    <bean name="/service/DataDictionaryUtilService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> 
    <property name="service" ref="lc.dct.dataDictionaryUtilService" /> 
    <property name="serviceInterface" value="com.adobe.dct.service.DataDictionaryUtilService" /> 
    </bean>

Invoke the data dictionary Util Service, and pass the data dictionary Id as parameter to get sample XML data for data dictionary.

HttpInvokerProxyFactoryBean httpInvokerProxyFactoryBean = new HttpInvokerProxyFactoryBean(); 
httpInvokerProxyFactoryBean.setServiceInterface(DataDictionaryUtilService.class); 
httpInvokerProxyFactoryBean.setServiceUrl(soapEndpoint + "/cmsa/remoting/service/DataDictionaryUtilService"); 
UsernamePasswordAuthenticationToken userAuthToken = new UsernamePasswordAuthenticationToken(userName, password); 
SecurityContextHolder.getContext().setAuthentication(userAuthToken); 
httpInvokerProxyFactoryBean.setHttpInvokerRequestExecutor(new AuthenticationSimpleHttpInvokerRequestExecutor()); 
httpInvokerProxyFactoryBean.afterPropertiesSet(); 
DataDictionaryUtilService ddUtilService = (DataDictionaryUtilService) httpInvokerProxyFactoryBean.getObject(); 
ddUtilService.getSampleXMLDataForDD(dataDictionaryId);

Invoke data dictionary through the Flex client

In order to use this sample you will have to add <dct_root>/client/flex/adobe-dct-flex-services.swc to your Flex project's classpath.

Get the singleton instance of data dictionary service.

 DataDictionaryUtilServiceImpl ddUtilService = DataDictionaryUtilServiceImpl.getInstance();

Invoke the data dictionary Util Service, and pass the data dictionary Id as parameter to export a data dictionary as annotated FML.

/** 
 *  Exporting Data Dictionary 
 */ 
private function exportAsFML(event:*):void 
{ 
  var ddId:String = //The id of an existing data dictionary. 
  ddUtilService.exportDataDictionaryAsFML(ddId, handleSuccess, handleFault); 
} 
/* Success Handler */ 
private function handleSuccess(event:DCTServiceEvent):void 
{ 
   var ddFML:String = event.data as String;         
} 
/* Fault Handler */ 
private function handleFaultevent:FaultEvent):void 
{ 
   trace("Error exporting DataDictionary"+ (event.message as ErrorMessage).faultCode );                  
}

Legal Notices | Online Privacy Policy


undefined
// Ethnio survey code removed