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:
-
Data Dictionary Browser. The user interface that enables browsing
a data dictionary and its elements.
-
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.
-
Java Development Tools:
-
LiveCycle Tools
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.
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
.
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.
-
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.
-
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.
-
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.
-
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:
-
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
.
-
The Business Process Owner can also use the Data Dictionary
Editor to create data dictionary by importing a schema.
-
On saving the data dictionary, the data dictionary metadata definition
gets stored in the back end ie in the asset manager.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
.
-
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 );
}
|
|
|