This document is intended to provide a detailed guide and examples on how to customize a Business Rule for opening id DELWKIDataCollectPlan_ReqAssociation_BL_ID
Introduction
This business logic is customized for those who want to use the Non-FTA Requirements (Requirements which are created manually in Requirement Widget or Application) to capture customer requirements and want to propagate them downstream processes like Process Planning and Work Instructions. This will enable to initialize the enrichment of Data Collect Plan Row Attributes using Requirement Rich Text or Requirement Parameters.
Whenever an "Requirement" is assigned to a "Data Collect Plan (DCP)", a new "Data Collect Plan Row" gets created in the "Data Collect Plan" and the assigned "Requirement" gets attached to the DCPR.
In the OOTB scenario, If the requirement is an FTA Requirement, then the attributes of the DCPR are filled with the Values fetched from the FTA. For example. Nominal Value is filled with FTA Nominal Value, Minimum value with Lower limit of FTA Tolerance, Maximum Value with Upper Limit of FTA Tolerance, Label with Name of FTA Requirement and Rich text with the image of the FTA Representation.
But, if the Requirement is a Non-FTA Requirement, then only the Rich text of Requirement and name are mapped with the Rich text and Label of DCPR Respectively.
Due to this, it was not possible to fill the DCPR Attributes from the Non-FTA Requirement. So, the Business Logic for the opening ID "DELWKIDataCollectPlan_ReqAssociation_BL_ID" was customized to support the enrichment of DCPR Attributes from the Rich Text of Non-FTA Requirement and the Requirement Parameters.
Version – 2024x FD04, 2025x GA
Pre-requisites:
Licenses –
PPL (Process Engineer): Required to create Mfg. Item Structure, Process objects and Work Instructions
TRM (Requirements Engineer): Required to Create Requirements (FTA or Non-FTA)
Disclaimer: Licenses mentioned above are as per 2024x and 2025x documentation.
PLM Opening ID | DELWKIDataCollectPlan_ReqAssociation_BL_ID |
Usage | Gets triggered when Requirement is Assigned to Data Collect Plan. Used to enrich the Data Collect Plan Row with the information available in the Assigned Requirement |
Working of the Provided Sample BL
The flow chart given below explains the working of the provided sample BL.
If the requirement is an FTA Requirement, then the requirement uses Tolerance Values of the FTA to enrich the attributes of the Data Collect Plan Row (DCPR)
If the Requirement is a Non-FTA Requirement, then:
If parameters are available, then it uses the first parameter available under the requirement and uses its values to enrich the DCPR attributes
If Parameter is not available, it checks if custom rich text contains some attribute values. If Attribute values are available in the rich text, it decodes the rich text and uses the values to enrich the attributes of DCPR.
Explanation
The customization of the business logic (DELWKIDataCollectPlanReqAssociation.CATRule) allows the automatic creation and enrichment of data collect plan rows when non-FTA requirements are assigned to them.
The customized Business Logic (BL) supports creation of various types of Data Collect Plan Rows (DCPR) like Real, Integer, Text, Boolean and Time Stamp.
The BL works in two ways for Non-FTA Requirements:
Using Requirement Parameters
Using Customized Rich Text of Non-FTA Requirements
A. Using Requirement Parameters to Initialize Data Collect Plan Row's Attributes
The sample script provided here supports the use of Requirement Parameters to initialize the attributes of Data Collect Plan Rows.
It supports the parameters of type Real, Integer, Boolean and String.
Also, it supports single value as well as multi value requirement parameters.
From Requirement Parameters, it can take Target Value (For Real Type of Parameters), Possible Values (For Integer, Boolean and String Type of Parameters), Minimum Value (For Real and Integer Type of Parameters) and Maximum Value (For Real and Integer Type of Parameters)
Note: To know "How to create Requirement Parameter" follow the section "Creating Requirements Manually using "Requirements Widget" on this page
Examples
DCPR Created from Real Type of Requirement Parameter
DCPR Created from Integer Type of Requirement Parameter
DCPR Created from String Type of Requirement Parameter
DCPR Created from Boolean Type of Requirement Parameter
Limitations:
1. If there are multiple Requirement Parameters available under a Non-FTA Requirement, then the BL will use the first parameter and its values to initialize the attributes of DCPR.
2. If the Non-FTA Requirement has both customized rich text (As given in above section "B") and requirement parameters associated with it, then the BL will prefer to use the requirement parameter to initialize the attribute of DCPR.
3. While creating a Requirement Parameter, though the unit selected is not a "SI" unit, while storing it in database, it is stored in "SI" units. For example, if one creates a Requirement Parameter of type Temperature with value 80 Degree Celsius, it is stored in database in "SI" unit, i.e. 353.15 Kelvin. So, while setting the value of DCPR, the sample BL will use the value from database, which is in "SI" unit. So, the unit of the DCPR will also be in "SI" system. So for the above example, the Value in DCPR will be "353.15 Kelvin" and not "80 Degree Celsius". But, if needed, one can change the unit downstream by editing the DCPR after it is created. The values will get automatically converted to the selected unit.
4. For now, with Requirement Parameters, Control Minimum and Control Maximum values are not supported by the provided sample BL. If needed, one can use the customized rich text to add these values (Please refer the above section "B").
B. Using Customized Rich Text to Initialize Data Collect Plan Row's Attributes
In some scenarios, requirements may be imported from MS Word Document or MS Excel Sheet. But, with those methods, requirement parameters cannot be imported. So, one can use the requirement rich text to store some values if needed. For example, temperature, pressure etc. Also, using custom rich text, one gets more control over the range of values like, in rich text it is possible to add control minimum and control maximum values as well.
In order to make this BL work with custom rich text, one need to format the Requirement Rich Text in a particulate format which is different for different types of DCPRs
Within the non-FTA requirements rich text, the following format needs to be respected for the BL to properly do the mapping:
Non-FTA Requirement Custom Rich Text Format to be used for the sample BL:
Below are few keywords/symbols used to add attribute information in the Rich Text of the Non-FTA Requirement.
Below are few keywords/symbols used to add attribute information in the Rich Text of the Non-FTA Requirement.
"|" (Pipe): Pipe is used to separate the attribute information from the rich text. In rich text of Non-FTA Requirement, one need add the information of attributes after the rich text in between two pipes. For example:
":" (Colon): Colon is used as the separator between an Attribute and its value in the Attribute Information part of the rich text. For example:
";" (Semi-Colon): Semi-Colon is used as the separator between two attribute-value pairs. For example:
"Magnitude": Magnitude of measurement to be taken. It should be as given in the excel file "Keywords for Magnitude and their MKS Units in 3DExperience Platform" given below. For example, TEMPRTRE for Temperature. Magnitude is needed for Real Type of DCPR only.
"NbMeasure": Number of Measurements to take.
"Unit": Unit of the Magnitude in SI Unit System. Only Required for Real Type of DCPR
"MinVal": Minimum Value
"CtrlMinVal": Control Minimum Value
"TargetVal": Nominal Value
"CtrlMaxVal": Control Maximum Value
"MaxVal": Maximum Value
"PossIntVal": Possible Values separated by "," (comma) for Integer type of DCPR
"PossBoolVal": Possible values for Boolean type of DCPR. Refer the below examples given for allowed possible values for Boolean DCPR
"PossTextVal": Possible values separated by "," (comma) for Text type of DCPR.
"TimeFormat": Time format for the Time Stamp type of DCPR. Refer the below examples given for allowed possible values for Time Stamp type of DCPR
Examples:
For Real Type of DCPR:
[RICH TEXT/IMAGES TO BE DISPLAYED IN DATA COLLECT PLAN ROW RICH TEXT]|Magnitude:TEMPRTRE;NbMeasure:5;Unit:KELVIN;MinVal:300.00;CtrlMinVal:303;TargetVal:305.00; CtrlMaxVal:308;MaxVal:310.00|
The "Magnitude" section can be non-intuitive and not understood in a 'natural' way by 3DExperience, for example, Temperature must be entered as 'TEMPRTRE' for it to be understood by the BL. Here an exhaustive list of these magnitudes and the corresponding MKS unit.
Important Note:
1. One needs to either:
a. Ensure the values entered in the "Val" fields are in SI units. The "Unit" field may be non-SI and the conversion is properly managed by the data collect plan row.
b. Manage the unit conversion downstream.
For Integer Type of DCPR:
[RICH TEXT/IMAGES TO BE DISPLAYED IN DATA COLLECT PLAN ROW RICH TEXT]|ReqType:Integer;NbMeasure:6;MinVal:0;CtrlMinVal:0;PossIntVal:1,2;CtrlMaxVal:4;MaxVal:2|
For Integer type of Data Collect Plan Row, Magnitude and Unit are not supported. The possible values should be separated by comma (“,”)
For Boolean Type of DCPR:
[RICH TEXT/IMAGES TO BE DISPLAYED IN DATA COLLECT PLAN ROW RICH TEXT]|ReqType:Boolean;NbMeasure:5;PossBoolVal:Yes_No|
The possible values can be: Yes_No, 1_0, True_False
For Text Type of DCPR:
[RICH TEXT/IMAGES TO BE DISPLAYED IN DATA COLLECT PLAN ROW RICH TEXT]|ReqType:Text;NbMeasure:5;PossTextVal:Possible Value 1, Possible Value 2, Possible Value 3|
The possible values for Text type of Data collect plan can be any textual statement/word. You can separate the multiple statement using comma (“,”).
For Timestamp Type of DCPR:
[RICH TEXT/IMAGES TO BE DISPLAYED IN DATA COLLECT PLAN ROW RICH TEXT]|ReqType: Timestamp;TimeFormat:hh_mm_ss|
The possible values for TimeFormat are hh_mm_ss, hh_mm and YYYY_MM_DD
Here is an example of a non-FTA requirements:
When the above requirements were assigned to the Data Collect Plants, the Data Collect Plan Rows got created were as given below:
Sample Business Logic
Disclaimer: This code is just an example and should only be used by people who know the Enterprise Knowledge Language (EKL) and the DELMIA data model very well. The intent is not to provide a ready to deploy product code. So we are not responsible for any issues you may face with this code.
IMPORTANT NOTES:
1. Here, only the customization of DELWKIDataCollectPlanReqAssociation.CATRule is shown but one may consider customizing DELWKIDataCollectChecklistReqAssociation.CATRule
2. Here the customized rich text and subsequent text processing is also used to the ease of importing such requirement structures from Word or Excel. But, one can use the Requirement Parameters to store the information, as the above BL supports the use of Requirement Parameters as well.
Business Rule Deployment
You may refer the below page for Business Rule deployment.
Deploying Using CATRule
How to Deploy the Custom Business Logic using CATRule?
Paste DELWKIDataCollectPlanReqAssociation.CATRule in [INSTALL PATH]\win_b64\resources\knowledge\scripts
For deployment using Data Setup app following Resource set ID and opening needs to be used:
Resource Set ID:
Opening ID:
Authors
For any queries, please reach out to @KA