SDI Data Management Service 示例应用¶
为两个跨域数据创建一个数据注册并上传文件¶
客户想要分析设计和工厂数据。客户首先为这两个源创建一个数据注册。 假设设计数据包含 XML 类型文件,而工厂数据包含 CSV 文件。因此,为每个源创建了两个数据标记。客户还希望附加来自设计团队生成的文件的数据,以便在输入XML文件性质不同时创建新版本,或者在模式没有变化但只有数据点更改时追加数据。客户希望替换工厂提供的输入文件的模式和数据。
先决条件¶
- 您具有正确分配的角色或技术用户凭据。
- 上传的文件是已支持的文件格式。
- 请根据使用的 SDI API 版本,在以下所有示例端点中替换 sdi_version 为 v3 或 v4。
为两个跨域数据创建一个数据注册¶
为两个源创建了两个数据注册。这可以通过端点实现:
POST /api/sdi/sdi_version/dataRegistries
对于设计数据源,请求体为:
{
"datatag": "classification",
"defaultRootTag":
"ClassificationCode",
"filePattern": "[a-zA-Z]+.xml
"fileUploadStrategy": "append",
"sourceName: "Design",
"metaDataTags": ["teamcenter"]
]
}
可以通过检查响应来验证:
{
"registryId": "24537F02B61706A223F9D764BD0255C8",
"sourceName": "design",
"dataTag": "classification",
"xmlProcessRules": [],
"metaDataTags": ["teamcenter"],
"defaultRootTag": "ClassificationCode",
"filePattern": "[a-z_A-Z0-9]+.xml",
"createdDate": "2019-10-21T16:16:08.783Z",
"updatedDate": "2019-10-21T16:16:08.783Z",
"mutable": false,
"fileUploadStrategy": "append",
"category": "ENTERPRISE"
}
对于工厂数据源,请求体为:
{
"datatag": "plantprocess",
"filePattern": "[a-zA-Z]+.csv
"fileUploadStrategy": "replace",
"sourceName: "Plant",
"metaDataTags": ["USAPlant"]
]
}
可以通过检查响应来验证:
{
"registryId": "3ADBD1C08D3625C5C0B2AEE9D06CC294",
"sourceName": "plant",
"dataTag": "plantprocess",
"xmlProcessRules": [],
"metaDataTags": ["USAPlant"],
"defaultRootTag": null,
"filePattern": "[a-z_A-Z0-9]+.csv",
"createdDate": "2019-10-21T16:16:56.466Z",
"updatedDate": "2019-10-21T16:16:56.466Z",
"mutable": false,
"fileUploadStrategy": "replace",
"category": "ENTERPRISE"
}
一旦创建了数据注册,客户就可以根据生成的数据注册执行上传。
上传两个跨域数据的文件¶
为两个源创建数据注册之后。可以使用以下端点上传不同的文件:
XML 类型文件
POST /dataUpload:
File = designxml.xml
CSV 类型文件
POST /dataUpload:
File = process.csv
一旦为一个给定的租户成功地上传了文件,用户就可以使用以下 REST POST API 端点开始数据摄取:
POST /ingestJobs
对于设计数据源,请求体为:
{
sourceName = Design
dataTag = classification
rootTag = ClassificationCode
filePath = designxml.xml
}
对于工厂数据源,请求体为:
{
POST /ingestJobs:
sourceName = Plant
dataTag = plantprocess
filePath = process.csv
}
一旦数据摄取过程开始,客户将为每个 POST 请求得到 jobId。jobId 说明了 SDI 系统的当前活动。SDI 系统将为上传的文件创建两种不同的模式,客户可以使用查询服务进行查询,也可以使用模式创建语义模型。
为 XML\PLMXML 创建高级数据注册¶
复杂\嵌套 XML 能够使用 xmlProcessRules 转换。用户可以通过忽略或索引规则来忽略或平铺嵌套元素。如果 xml 包含嵌套元素,则在创建注册 时将该规则添加到 xmlProcessRules
。
请求体:
<Occurrence id="id33">
<UserData id="id32" type="AttributesInContext">
<UserValue value="" title="OccurrenceName"> </UserValue>
<UserValue value="1400" title="SequenceNumber"></UserValue>
<UserValue value="" title="ReferenceDesignator"></UserValue>
</UserData>
</Occurrence>
<ProductRevision id="id79" name="90214255__001__PART_WF" accessRefs="#id4" subType="ItemRevision" masterRef="#id80" revision="aa">
<AssociatedDataSet id="id81" dataSetRef="#id78" role="PhysicalRealization </AssociatedDataSet>
<AssociatedDataSet id="id181" dataSetRef="#id180" role="PhysicalRealization"></AssociatedDataSet>
<AssociatedDataSet id="id205" dataSetRef="#id204" role="PhysicalRealization"></AssociatedDataSet>
</ProductRevision>
对于索引规则,title
值实际上是一个转换/平铺列,而不是 title
本身。转换规则的有效注册为:
{
"dataTag": "occ",
"filePattern": "[a-zA-Z0-9]+.xml",
"fileUploadStrategy": "append",
"defaultRootTag":"Occurrence",
" xmlProcessRules ": [
"Occurrence.UserData.UserValue.index=title"
],
"sourceName": "teamcenter"
}
在本例中,index
标记定义转换规则,而不是把 Occurrence.UserData.UserValue_value
和 Occurrence.UserData.UserValue_title
作为一个列系统将处理 Occurrence.Userdata.UserValue.OccurenceName.value
作为转换后的列。
对于忽略规则,请求体为:
{
"dataTag": "productrev",
"filePattern": "[a-zA-Z0-9]+.xml",
"fileUploadStrategy": "append",
"defaultRootTag":"ProductRevision",
" xmlProcessRules ": [
"ignore=AssociatedDataSet"
],
"sourceName": "teamcenter"
}
在本例中,Ignore
标记定义需要忽略的元素。在这种情况下,处理过程中将忽略AssociatedDataSet
的所有元素和子元素。
在模式生成期间创建自定义数据类型¶
客户希望根据示例数据找到示例正则表达式,并创建自己的自定义数据类型,以便 SDI 系统在模式生成期间使用。有些数据包含员工的电子邮件地址。
这可以通过端点实现:
POST /sdi/api /sdi_version/suggestPatterns
以上示例值的URL模式如下所示:
/api/sdi/sdi_version/suggestPatterns?sampleValues=myrealemployee@realemail.com&testValues=anothertrueamployee@realemail.com, notmyemail@notmyemail.com
这将生成两个模式。客户可以使用注册数据类型端点注册模式。
[
{
"schema": "[a-z]+[@][a-z]+email.com",
"matches": [false,true],
"schemaValid": true
},
{
"schema": "[a-z]+[@][a-z]+[\\.][a-z]+",
"matches": [false, true],
"schemaValid": true
}
]
搜索模式¶
库存零件数据从 ERP 输入到 SDI。摄取的文件是 CSV 格式。搜索模式 POST 方法将提供该摄取文件的模式,其中包含属性名和数据类型。 使用 POST 方法: /searchSchemas
可以检索作业完成状态文件的模式。请求有效载荷为:
{
"schemas": [ -> The elements in this list must be similar, each element must contain homogenous parameters. (a combination of dataTag, sourceName and schemaName)
{
"dataTag": "string",
"schemaName": "string",
"sourceName": "string"
}
]
}
{
"schemas": [ -> The elements in this list must be similar, each element must contain homogenous parameters. (a combination of dataTag, sourceName, metadataTags and schemaName)
{
"dataTag": "string",
"schemaName": "string",
"sourceName": "string",
"metaDataTags": ["string"]
}
]
}
{
"schemas": [ -> The elements in this list must be similar, each element must contain homogenous parameters. (like metadataTags)
{
"metaDataTags": ["string"]
}
]
}
为两个跨域数据 IDL 用户创建数据注册的示例¶
客户对分析设计和工厂数据感兴趣。在本例中,客户首先为这两个源创建一个数据注册。假设设计数据包含 XML 类型文件,工作数据包含 CSV 文件,因此客户为每个源创建两个数据标记。客户还希望附加来自设计团队生成的文件的数据,以便在输入XML文件性质不同时创建新版本,或者在模式没有变化但只有数据点更改时追加数据。客户希望替换工厂提供的输入文件的模式和数据。
POST /api/sdi/sdi_version/dataRegistries:
{
"datatag": "classification",
"defaultRootTag":
"ClassificationCode",
"filePattern": "[a-zA-Z]+.xml",
"fileUploadStrategy": "append",
"sourceName: "Design",
"metaDataTags": ["teamcenter"]
]
}
POST /api/sdi/sdi_version/dataRegistries:
{
"datatag": "plantprocess",
"filePattern": "[a-zA-Z]+.csv",
"fileUploadStrategy": "replace",
"sourceName: "Plant",
"metaDataTags": ["USAPlant"]
]
}
一旦创建了数据注册,客户就可以使用 IDL 基于以上通过数据注册创建的 registryId
执行上传。
Schema 进化示例¶
本节解释 schema 进化如何适用于给定的输入文件和数据注册。
数据注册: NHTSA (源), Vehicle (数据标签)
摄取的文件序列和测试数据¶
- 文件名称: vehicle_202001.csv 包含示例数据:
ID | Name | MfgDate |
---|---|---|
12345 | AwesomeCar | 12:20:2015 |
34555 | AnotherAwesomeCar | 13:01:2016 |
32131 | AnotherAwesomeCar | 01:12:2019 |
GeneratedSchema:
id: integer name:string mfgdate:timestamp
- 文件名称: vehicle_202002.csv 包含示例数据:
ID | Name | MfgDate |
---|---|---|
34-456 | OKCar | 12:20:2020 |
34555 | AnotherAwesomeCar | 13:01:2016 |
32131 | AnotherAwesomeCar | 01:12:2019 |
GeneratedSchema:
id: string. name:string mfgdate:timestamp 由于记录数限制最大5000,属性**id**的类型从**integer**更改为**string**。因此,SDI 将允许 schema 进化以及和数据类型改变。
- 文件名称: vehicle_202003.csv contains sample data:
ID | Name | Price | MfgDate |
---|---|---|---|
34-456 | OKCar | 25000 | 12:20:2020 |
34555 | AnotherAwesomeCar | 50000 | 13:01:2016 |
32131 | AnotherAwesomeCar | 55000 | 01:12:2019 |
GeneratedSchema:
id: string name:string mfgdate:timestamp price:integer 在该情况下,schema 将进化模并添加新列**price**。
- 文件名称: vehicle_202004.csv 包含示例数据:
ID | Name | Price | MfgDate |
---|---|---|---|
34-567 | GreatCar | 65810.45 | Unknown |
34555 | AnotherAwesomeCar | 50000 | 13:01:2016 |
32131 | AnotherAwesomeCar | 55000 | 01:12:2019 |
GeneratedSchema:
id: string name:string mfgdate:string price:float
由于记录数限制最大5000,属性**mfgdate**的类型从**timestamp**更改为**string**。属性**price**的数据类型从**integer**更改为**float**。因此 SDI 将允许 schema 的进化以及数据类型改变。
- 文件名称: vehicle_202005.csv 包含示例数据: 5000条记录后
ID | Name | Price | MfgDate |
---|---|---|---|
34-789 | AwesomeCar | Unavailable | Unknown |
34555 | AnotherAwesomeCar | 50000 | 13:01:2016 |
32131 | AnotherAwesomeCar | 55000 | 01:12:2019 |
This results in error as SDI is unable to convert column price to String because of incompatible type-source float, incoming is string and record limit has reached to 5000. So type change is not allowed during schema evolution. 这将导致错误。由于类型源不兼容,传入的是 String**并且记录限制已经达到5000,SDI 无法将列 **price 转换为**String**。因此在 Schema 进化期间不允许进行类型更改。
- 文件名称: vehicle_202006.csv 包含示例数据: 5000条记录后
ID | Name | Price | MfgDate |
---|---|---|---|
2356 | AwesomeCar | 95000 | 13:01:2024 |
34555 | AnotherAwesomeCar | 50000 | 13:01:2016 |
32131 | AnotherAwesomeCar | 55000 | 01:12:2019 |
GeneratedSchema:
id: string- 基于现有类型,传入类型更改为包含类型字符串。 name:string mfgdate:string 基于现有类型,传入类型更改为包含类型字符串。 price:float
属性 id 和 mfgdate 的类型是 string,因为现的类型是 string。因此传入的数据类型被更改为**string**,以使 schema 一致。