Notifications
Clear all
Topic starter
Hi. Our organization is taking some forms and doing a mass transformation of document variables to obs terms for future reporting purposes. I'm familiar, but not proficient in this and am wondering if the transformation of something like this (example of a function in an assessment/plan form) will have any unintended consequences.
Document variable version:
{fnProbDropdown_AP(PROB_AFTER("delimited"),DOCUMENT.AP_1_LC,DOCUMENT.AP_2_LC,DOCUMENT.AP_3_LC, DOCUMENT.AP_4_LC,DOCUMENT.AP_5_LC,DOCUMENT.AP_6_LC, DOCUMENT.AP_7_LC,DOCUMENT.AP_8_LC,DOCUMENT.AP_9_LC, DOCUMENT.AP_10_LC, DOCUMENT.AP_11_LC, DOCUMENT.AP_12_LC,"1") + "," + gOtherDxs}
Obs version:
{fnProbDropdown_AP(PROB_AFTER("delimited"),OBSNOW("A&P#1"),OBSNOW("Ass2AP1-2"),OBSNOW("Ass1AP3-4"),OBSNOW("Ass2AP3-4"),OBSNOW("Ass1AP5-6"),OBSNOW("Ass2AP5-6"),OBSNOW("Ass1AP7-8"),OBSNOW("Ass2AP7-8"),OBSNOW("Ass1AP9-10"),OBSNOW("Ass2AP9-10"),OBSNOW("Ass1AP11-12"),OBSNOW("Ass2AP11-12"),"1") + "," + gOtherDxs}
Posted : August 23, 2019 8:19 am
On the face of it, that should be find and everything in the function should work the same way, regardless of the parameters being document variables or observation terms. The function code itself will only care about the values they contain, not where they originate.
Posted : August 26, 2019 4:49 am
One thing you might want to test for is speed. If you have a lot of data points and you are going from document variables to obs terms you might see the form run a bit slower. There are ways around this by keeping your document variables and calling a function whenever the document variable is updated to push to the needed obs term. Another user shared this idea with me when I was looking for ways to speed things up on our forms. Take a look at this thread for discussion/code:
https://forum.centricityusers.com/forum/unit-testing-for-speed/
Posted : August 27, 2019 1:28 am
Hi Amanda,
The main issue will be in recursive execution. When obsterms are initialized in function calls, only one obsterm is 'triggered' at a time, meaning that for each instance that the function call is initiated, it will be triggered multiple times. In your example, that could be up to 14 times (12 obsterms, 1 prob after, and 1 gVar). Given that it appears you are using 12 fields, that is potentially 168 executions of the code just to initialize it on form load. While it might not be that heavy, you will want to evaluate it against all of the other forms in an update to ensure the performance hit is not undesirable. Should it prove to be too much, you could retain the document variables and assign them to obsterms directly in the MEL window of VFE (i.e. {! OBSNOW("A&P#1", DOCUMENT.AP_1_LC)}. In this manner, you maintain the efficiency of the doc vars whilst storing the values as desired in obsterms.
Posted : August 27, 2019 4:43 am
Topic starter
Thanks everyone. Very helpful. I will pass this info along.
Posted : August 28, 2019 9:14 am
Topic starter
Thanks very much for the replies. Very helpful.
Posted : September 6, 2019 5:59 am
