The following examples use this product with type = 'Item', ID 'XYZ', and Name = 'XYZ Name.' The product is located in the family 'FamilyXYZ2.'
The STEP Mongo Adapter transforms this to the STEP JSON document:
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : “Arm chair",
type : "product"
}
The id of the product is used as unique ObjectId in the MongoDB database, and therefore the STEPXML id field is transformed to _id. The UserTypeID XML attribute is converted to the objectTypeID field. The type field describes the kind of STEP object that is exported. For Basic STEP objects, the types are 'product', 'asset', 'classification', and 'entity.' Other STEP objects are described in the following topics.
Values
In this example, a product has two attributes:
- A single value attribute Color with the value 'Brown'
- A multi value attribute Height with the value = '43', the unit = 'inches', and the value = '120', with the unit = 'cm.'
When this is transformed to a STEP JSON document by the STEP MongoDB adapter, it results in the following:
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : “Arm chair",
type : "product"
values : {
Color : "Brown",
Height : [ "43 inches", "120 cm"]
}
}
The data displayed includes:
- Values of the product are stored as a subdocument with the name 'values.'
- The value of the single-valued attribute 'Color' is represented as a field-and-value pair: the ID of the attribute is the field, and the value is the value of the attribute represented as a string.
- The multi-valued attribute 'Height' is represented as a field-to-arrays of strings. Again, the ID of the attribute is the field, and the string array contains a string for each value.
- The name of the unit is appended to the attribute value with a space for all values with a unit. In the example above, '120 cm' is the concatenation of the value '120' and 'cm' from the unit named 'unece.unit.CM.'
Values of specification attributes that are inherited to the product are included in the JSON document of the product. For example, if the parent contains an attribute called Brand with the value 'Office chairs', the JSON document looks like the following:
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : “Arm chair",
type : "product"
values : {
color : "Brown",
Height : [ "43 inches", "120 cm"],
Brand: “Office chairs”
}
}
LOV Value IDs
When values are included from an LOV that uses Value IDs (via the parameter 'Use Ids on values' = Yes on the LOV), the Value and the ValueID are stored as a subdocument with the name 'extValues.' For backward compatibility, the LOV value is also included in the 'value' subdocument, meaning this data is available twice, and can be extracted based on the need.
Note: If the LOV does not use Value IDs, the extValues subdocument is not written.
In this example, the LOV value of '4001' has a Value ID of '4001_CALYPSO.'
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : "Arm chair",
type : "product"
values : {
color : "Brown",
Height : [ "43 inches", "120 cm"],
Brand: "Office chairs"
attribute_id: "4001",
},
extValues: {
attribute_id: {
value: "4001",
valueID: "4001_CALYPSO"
}
}
The data displayed includes:
- The selected LOV value is stored within the subdocument with the name 'values' in the attribute_id field and again with the 'extValues' subdocument in the 'attribute_id: {value:' field.
- The value ID of the selected LOV value is represented once with the 'extValues' subdocument in the 'attribute_id: {valueID:' field.
References and Links
References and links are converted to STEP JSON in a subdocument called 'references.' This subdocument contains a field-and-value pair, where the field is the ID of the reference type, and the value is either a subdocument that defines the target of a reference, or an array of subdocuments that each define the target of a reference.
If the reference can only reference one target for the same source, the value is a subdocument. If the reference can reference more targets for the same source, the value is an array.
In this example, the product uses a 'Primary Image' asset reference to reference the image for the product. The asset has the ID 'Image_EXA-5002-1001.' The STEP JSON then exports as:
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : “Arm chair",
type : "product"
values : {
color : "Brown",
Height : [ "43 inches", "120 cm"],
Brand: “Office chairs”
}
references : {
Primary Image : { targetID : "Image-EXA-5002-1001" }
}
}
To find the asset for the reference, it is necessary to find the reference type 'Primary Image', which is stored in the raw collection 'referenceType.' The target type of the reference comes from the reference type.
The JSON of the reference target is found by searching the raw collection given by the reference type of an object with 'targetID.'
In the example above, the target type of the 'Primary Image' reference type is 'asset.' By looking in the 'asset' raw collection, the asset given by Image-EXE-5002-1001 is found.
Adding the reference 'Secondary Image', which can reference more targets such as ('Image1' and 'Image2') to the product, results in the following STEP JSON:
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : “Arm chair",
type : "product"
values : {
color : "Brown",
Height : [ "43 inches", "120 cm"],
Brand: “Office chairs”
}
references : {
Primary Image : { targetID : "Image-EXA-5002-1001" },
Secondary Image : [ { targetID : "Image1" }, { targetID : "Image2" } ]
}
}
If the reference contains a meta data attribute, the values of the meta data attribute are added as a subdocument to the reference subdocument that contains the value of the attribute:
{
_id : "EXA-5002-1001",
objectTypeID : "Chair",
parentID : "Chairs",
name : “Arm chair",
type : "product"
values : {
color : "Brown",
Height : [ "43 inches", "120 cm"],
Brand: “Office chairs”
}
references : {
Primary Image : { targetID : "Image-EXA-5002-1001",
values: { ShowOnWeb : “true” },
},
Secondary Image : [ { targetID : "Image1" }, { targetID : "Image2" } ]
}
}
The reference type 'Primary Image' has a meta data attribute called 'ShowOnWeb.' The attribute is set to 'true' for the reference from the product to the asset 'PrimaryAsset.'
Classification to product links are special because they are owned by either the product or the classification. This will always be the same for a specific classification to product link type. The JSON document only contains the classification-to-product links owned by the object. That is, the JSON document for a product only contains classification-to-product links owned by the product.
Attribute Types
Exporting an attribute type with the ID 'AttributeTypeID', and the name 'Name' linked in two parent attribute groups 'Parent1' and 'Parent2' results in the following JSON:
{
_id : "AttributeTypeID",
parentID : [ “Parent1", “Parent2”],
name : "Name",
listOfValuesID : "ListOfValuesID",
validUnitIDs : ["unece.unit.MMT", "unece.unit.CMT"],
type : "attribute"
}
Reference types are stored in the raw collection 'attribute.' To export reference types, verify that 'Include Attribute Definitions' is set to at least 'Selected' in the Process Engine configuration.
Data Containers
For both entities and products, data containers associated with these objects will be included, if included in the export configuration. A 'dataContainers' property will contain all of the associated attributes in this data container:
{
"_id":"CommonPlaceBook",
"objectTypeID":"Product user-type root",
"dataContainers":{
"DC-2127822":{
"values":{
"Color":"Red",
"Height":"12 in",
"Width":"9 in"
},
"extValues":{
"Color":{
"value":"Red"
},
"Height":{
"unitID":"unece.unit.INH",
"value":"12"
},
"Width":{
"unitID":"unece.unit.INH",
"value":"9"
}
}
}
},
"name":"Robert Black's Commonplace Book",
"type":"product",
"parentID":"TopNode"
}
In this example, the attributes 'Color,' 'Height,' and 'Width' in the single valued Data Container DC-2127822 are all exported to JSON.
In case of a multivalued data container, the content will always be exported as an array:
"ContEmailDataContainer": [
{
"extValues": {
"CalcContEmailDataContainer": {
"value": "313bobby@stibosystems.net"
},
"ContEmail": {
"value": "313bobby@stibosystems.net"
}
},
"values": {
"CalcContEmailDataContainer": "313bobby@stibosystems.net",
"ContEmail": "313bobby@stibosystems.net"
}
}
],
The values in the data containers are within the square brackets.
Reference Types
Exporting a product-to-product reference type with the ID 'ReferenceTypeID' and the name 'ReferenceName' generates the following JSON:
{
_id : "ReferenceTypeID",
name : "ReferenceName",
type : "referenceType",
targetType : “product”
}
In this example, 'targetType' is the target type of the reference. Possible target types are 'product','asset', 'classification', and 'entity.'
Reference types are stored in the raw collection 'referenceType.' When you export reference types, verify that Configuration > Include Link, Reference and Object Types is set to at least 'Minimum' in the Process Engine configuration.
Asset Push Locations
Asset Push Locations are stored in the assetPushLocations subdocument, in the root of the Asset documents in the asset collection. It provides the relative path to different versions of the asset. The assetPushLocations subdocument contains field-and-value pairs, where the field name is the assetpush configuration id, and the value is the relative path that the image file has been pushed to. The relative path is relative to the AssetPushClients root folder, so to get the full path of the image, you have to prepend the path to the assetpush client root directory, as shown in the following example:
assetPushLocations : {
AllAssets-approved : "AllAssets-approved/std.lang.all/73/15/7315.pdf",
AllWebsiteImages-approved : "AllWebsiteImages-approved/std.lang.all/73/15/7315.pdf",
small : "small/std.lang.all/73/15/7315.jpg",
large : "large/std.lang.all/73/15/7315.pdf"
}
Tables
Tables are defined on classifications or products. The table subdocument is stored in the root of the product and classification document, in the product and classification collection. The table subdocument contains field-and-value pairs, where the field name is the table Type name of the table on the product or classification.
A table is exported from STEP in a resolved and transformed state. That is, any transformations defined in STEP have already been applied to the table and the row and column layout has therefore been resolved.
Formatting is not applied to the table before it is exported. So, a web application is not bound by the STEP table formatting. However, if any formatting has been defined for the table in STEP, it is included in the export so that the website application can be configured to render the formatting on the website.
The table contains an array of column elements that contain the formatting meta data for each column and an array of rows. The row contains the formatting information for each row, plus an array of cells. Each cell has a number of formatting meta data attributes and a text field that contains the content of the table cell.
Table Formatting
Formatting meta data can be stored on table, column, row, and cell level, and is inherited downwards from table level to column level to row level to cell level.
If a column is specified to use an underlined text style, and a row is specified to be bold text style, the formatting information is accumulated so that the cell at the intersection of the row and column is rendered as both underlined and bold.
Formatting meta data defined at a lower level overrides meta data at a higher level. For example, if a table has a gray background color, and a column has a red background color, then cells in that row are rendered with a red background.
A simple way of formatting a table in HTML is to map the tableType, columnType, and rowType to element classes in HTML, and then use a CSS style sheet to define the table formatting, as shown in the following example.
tables : {
Description Table : {
columns :
[ { columnType : "Description" }, { columnType : "Description" }, { columnType : "Description" } ],
rows : [
{ rowType : "Header",
cells : [
{ ruleRight : "0.5 pt",
text : "Header 1",
verticalAlignment : "top",
cellStoryDirection : "horizontal",
backgroundColor : "Light Blue",
column : "0",
ruleBelow : "0.5 pt",
ruleAbove : "0.5 pt",
textStyle : "TableHeader—Description",
ruleLeft : "0.5 pt" },
{ ruleRight : "0.5 pt",
text : "Header 2",
verticalAlignment : "top",
cellStoryDirection : "horizontal",
backgroundColor : "Light Blue",
column : "1",
ruleBelow : "0.5 pt",
ruleAbove : "0.5 pt",
textStyle : "TableHeader—Description",
ruleLeft : "0.5 pt" }] },
{ rowType : "Header",
cells : [
{ ruleRight : "0.5 pt",
text : "Value 1",
verticalAlignment : "top",
cellStoryDirection : "horizontal",
backgroundColor : "Light Blue",
column : "0",
ruleBelow : "0.5 pt",
ruleAbove : "0.5 pt",
textStyle : "TableHeader—Description",
ruleLeft : "0.5 pt" },
{ ruleRight : "0.5 pt",
text : "Value 2",
verticalAlignment : "top",
cellStoryDirection : "horizontal",
backgroundColor : "Light Blue",
column : "1",
ruleBelow : "0.5 pt",
ruleAbove : "0.5 pt",
textStyle : "TableHeader—Description",
ruleLeft : "0.5 pt" }] }
] } }
Attribute Links
AttributeLinks define the validity of attributes for products linked into the product and classification hierarchies. The attributeLinks subdocument is stored at the root of the product and classification document structure. The attribute links can themselves contain a values subdocument that defines the meta data values attached to the attributeLink.
The attributeLinks subdocument contains field value pairs, where the field name is the attributeID, and the value is a subdocument that contains any meta data values related to the attribute link. The following is an example of an attributeLinks subdocument:
attributeLinks : { Voltage range : { }
Rotary address switches : { },
Default address : { },
Power consumption : { }
}
Data Container Type Links
The validity for Data Container Types for products can be restricted to products in certain product and/or classification hierarchies just like attributes can.
If the classification or product root to which a data container is restricted is exported, then the following JSON subdocument is returned:
"dataContainerTypeLinks": [ "ProdDC" ]
The following example is an export of the product root node called 'TopNodeWDC.' In this case, both the 'SpecificationAttribute' attribute is restricted to this root node, and the 'ProdDC' data container is restricted to this root node. This export returns an attributeLinks subdocument (as described in the 'Attribute Links' section) and a new dataContainerTypeLinks subdocument:
{
"_id": "TopNodeWDC",
"attributeLinks": {
"SpecificationAttribute": {}
},
"dataContainerTypeLinks": [
"ProdDC"
],
...
}
Data Containers Types
Data Container types collection contains the definition of the data containers. These collections may include metadata of the data container. The JSON will look similar to the following:
{
"_id":"DC-2127822",
"name":"Product Description",
"type":"datacontainertype",
"multiValued":"false"
}
{
"_id": "ContPhoneDataContainer",
"extValues": {
"DC Long Description": {
"value": "This DC is used for Phone numbers"
}
},
"multiValued": "true",
"name": "Phone",
"type": "datacontainertype",
"values": {
"DC Long Description": "This DC is used for Phone numbers"
}
}
Unit
Exporting an unit with the ID 'unece.unit.CMT', and the name 'cm' results in the following JSON:
{
"_id" : "unece.unit.CMT",
"values" : {
"4941" : "centimeter"
},
"conversionToBase" : {
"factor" : "100",
"unitID" : "unece.unit.MTR",
"offset" : "0"
},
"name" : "cm",
"type" : "unit"
}
The unit document contains the 'conversionToBase ' object that can be used for converting values from a unit to its base unit. The 'conversionToBase ' object of the above example shows how to convert values of the unit centimeters to meters.
Units are stored in the raw collection 'unit.' To export units, verify that Configuration > Include Units is set to at least 'Minimum' in the Process Engine configuration.
List Of Values
Exporting a ListOfValues object with the ID 'LOVID', and the name 'List of values' results in the following JSON:
{
"_id" : "LOVID",
"values" : {
"6823" : "This is a metadata value of the lov'"
},
"name" : "List of values",
"validUnitIDs" : [
"unece.unit.CMT",
"unece.unit.MTR"
],
"type" : "listofvalues"
}
List Of Values are stored in the raw collection 'listofvalues.' To export List Of Values, verify that 'Include List Of Values Definitions' is set to at least 'Minimum' in the Process Engine configuration.