With the introduction of XSteps as an improvement over the classical process instructions, the design and programming of PI sheets has become a lot easy. We have moved from the days of programming the process instructions to drag-and-drop of controls. There has been a paradigm shift with more focus on data, which is realized in terms of XStep parameters. XSteps enforces a strict grammar on the accessibility and reusability of the parameters. Thus, ensuring consistency and integrity of data.
XSteps is surprisingly flexible and powerful for a tool having strict rules and guidelines on data access and manipulation. In a balancing act between flexibility of data access and maintaining its integrity, it is quite natural to come across a few limitations. In this article I wish to address one such limitation and provide a workaround mechanism.
During the design of XSteps you may come across a requirement to copy the contents of a table parameter (Value One) in a repeated data request (Table One) to another table parameter (Value Two) in a different repeated data request (Table Two). In short, create the table column once either through inputs or calculation and use it elsewhere. The main purpose is to keep these two columns in sync dynamically.
Something like this.
Technically when the value of a normal parameter is to be referenced, you create an output/local parameter in the source XStep and define an input parameter in another XStep. This ensures the value of the first parameter is reflected in the referenced parameter. The same mechanism, however, does not work if you wish to refer the whole column of parameters and refer it to another table.
This is due to a limitation of XSteps referencing mechanism. It only works with single parameter references.
How to achieve this functionality?
Yes, it is possible with a little bit of extra help from the framework. We can use a Copy function module and the PARAMETER_CHANGED event to keep the two table parameters from different tables in sync.
Here is the step-by-step description of the process:
Step 1: Create a table type with only one column. The line type of this table should be the same as the data type of the column you wish to reference. In this example, I have kept it simple as INT4.
Step 2: Create a Z function module with reference input as the table type Z_INTTAB and outputs the same table type. We use this FM to copy the input to the output table parameter every time it’s called.
Step 3: Create a hierarchy among the XSteps: This is important because XStep values can only move from parent to child and vice-versa. There is no peer exchange of XStep parameters. See XStep Parameters.
Step 4: Create the parameters in the parent XStep (Table One) where user input happens, and the table acts as the source.
LV_PAR1 and LV_PAR2 are two input parameters. Their sum is calculated and stored in LV_PARH.
Step 5: Define an input parameter LV_PARAM4 in the child XStep (Table Two)
Step 6: Important – In the Child XStep, the parameter LV_PARAM4 will refer to the LV_PARH of Table One.
Step 7: Since LV_PARAM4 is a reference to LV_PARH of the parent, there is a need to store this table in a separate location for any changes to be visible in the child XStep.
So, use the FM Z_AJ_TABLE_COPY to copy LV_PARAM4 to LV_PARCO as follows in the Child. The usage of PARAMETER_CHANGED event ensures any change in the parent is propagated to the child.
Verify the generated Process Instructions.
Process Instruction Characteristics of the Parent XSteps:
Process Instruction Characteristics of the child XSteps:
Summarising the mechanism:
With these 7 simple steps I believe we have found a perfect workaround to copy the contents of a column in a repeated data request to a different column in another repeated data request.
In summary, we use the following logic:
Adding a new row to Table One and triggering calculation would reflect the calculated value in Table Two.
I have found this mechanism working perfectly for some time now. I request you to please share any different methods you used to achieve this functionality.
Okumaya devam et...
XSteps is surprisingly flexible and powerful for a tool having strict rules and guidelines on data access and manipulation. In a balancing act between flexibility of data access and maintaining its integrity, it is quite natural to come across a few limitations. In this article I wish to address one such limitation and provide a workaround mechanism.
During the design of XSteps you may come across a requirement to copy the contents of a table parameter (Value One) in a repeated data request (Table One) to another table parameter (Value Two) in a different repeated data request (Table Two). In short, create the table column once either through inputs or calculation and use it elsewhere. The main purpose is to keep these two columns in sync dynamically.
Something like this.
Technically when the value of a normal parameter is to be referenced, you create an output/local parameter in the source XStep and define an input parameter in another XStep. This ensures the value of the first parameter is reflected in the referenced parameter. The same mechanism, however, does not work if you wish to refer the whole column of parameters and refer it to another table.
This is due to a limitation of XSteps referencing mechanism. It only works with single parameter references.
How to achieve this functionality?
Yes, it is possible with a little bit of extra help from the framework. We can use a Copy function module and the PARAMETER_CHANGED event to keep the two table parameters from different tables in sync.
Here is the step-by-step description of the process:
Step 1: Create a table type with only one column. The line type of this table should be the same as the data type of the column you wish to reference. In this example, I have kept it simple as INT4.
Step 2: Create a Z function module with reference input as the table type Z_INTTAB and outputs the same table type. We use this FM to copy the input to the output table parameter every time it’s called.
Step 3: Create a hierarchy among the XSteps: This is important because XStep values can only move from parent to child and vice-versa. There is no peer exchange of XStep parameters. See XStep Parameters.
Step 4: Create the parameters in the parent XStep (Table One) where user input happens, and the table acts as the source.
LV_PAR1 and LV_PAR2 are two input parameters. Their sum is calculated and stored in LV_PARH.
Step 5: Define an input parameter LV_PARAM4 in the child XStep (Table Two)
Step 6: Important – In the Child XStep, the parameter LV_PARAM4 will refer to the LV_PARH of Table One.
Step 7: Since LV_PARAM4 is a reference to LV_PARH of the parent, there is a need to store this table in a separate location for any changes to be visible in the child XStep.
So, use the FM Z_AJ_TABLE_COPY to copy LV_PARAM4 to LV_PARCO as follows in the Child. The usage of PARAMETER_CHANGED event ensures any change in the parent is propagated to the child.
Verify the generated Process Instructions.
Process Instruction Characteristics of the Parent XSteps:
Process Instruction Characteristics of the child XSteps:
Summarising the mechanism:
With these 7 simple steps I believe we have found a perfect workaround to copy the contents of a column in a repeated data request to a different column in another repeated data request.
In summary, we use the following logic:
- We use a Copy function module to copy the table parameter to another.
- We use the PARAMETER_CHANGED event to trigger this Function module.
Adding a new row to Table One and triggering calculation would reflect the calculated value in Table Two.
I have found this mechanism working perfectly for some time now. I request you to please share any different methods you used to achieve this functionality.
Okumaya devam et...