Is there any rule in Documaker 12.1 ODSE to control the ordering of forms at run-time. We have our forms triggered based on XML node <Form> and would like to have the forms ordered in the way the node comes in XML . The XML Structure would look like below .
There isn't a rule that would allow you to do that. But the bigger question: what is the business need behind this requirement? It goes against the principle design of having a structured form order set that is controlled.
I have seen this done through use of Subforms and a complex data structure, but it would involve a long discussion to describe this and isn't suitable for this forum. Guidance can be provided by Oracle IGBU Consulting if required.
Using this structure you can trigger the Subform on !/Formlist/Subform.
This would be a single Subform below the Forms List.
This would reference another Subform that contains each form that can be triggered individually on the specific ID below !/Formlist/Subform/Form
Thanks for your information. Currently we are in Documaker 11.3 and custom rules are created to trigger and order the forms based on the values in the XML Node. Since we are migrating to 12.1 we are looking in to the feasibility of having these custom rules replaced by the base rules.
Prior to 11.5, other than the previous suggestion, you could use DAL to add the forms in the order you want, but this would not execute your section level triggers. That means if you have optional sections or repeating sections, you would then have to try to handle that yourself too.
Starting in 11.5 a new DAL function is available in Gendata processing called TRIGGERFORM(). This has the ability to add the form and also execute the trigger rules on the sections. So, if you are moving to 12.1, you might investigate whether you could simply do your own PreTransDAL script to to TRIGGERFORM() instead of relying on normal trigger rules.
Did you get this using any rules or any DAL logic you followed ? I thought this can be done through DAL and tried using below sample DAL code.
Still i didnt get the form order as it comes from XML node.
What you have defined in that script is really just a generic trigger for the forms to check to see whether they are defined in the XML. This does not alter the order that the forms are evaluated - which is defined in the Forms List grouping (GRP) file.
If you want to achieve your own order, you would replace the RunTriggers rule with a PreTransDAL rule to call a script that would loop through the elements and attempt to trigger the forms manually in the order that you want.
Note, XMLFormOrder will be a DAL stored in my library. I won't guarantee this syntax, but XMLFormOrder.DAL would look something like this (based upon what you had in your script):
You will see that I used SrchData() instead of GetData() as you did. The result is the same, but I like breaking out the offset and length of the data as separate parameters rather than having to include it in the search string parameter as GetData() requires. Both functions support an option parameter at the end that is an “instance” or “occurrence” number. In this case, start #cnt at 1 and keep incrementing. As soon as you get no string value returned from the search, you know you have exceeded your list and break out. You can do the CountRecs() first, if you like, and then you would know where to stop.
In this case, the form name you want to trigger does not even have to be in the Forms List (GRP) file that is active. If you do want to add the forms to your GRP file (because it helps define the structural relationship for anyone looking at library resources) that is fine, but you would not want to add a trigger on the forms. Otherwise, you will now get the forms triggered twice.
If you did want additional forms to be able to trigger that are not listed in your XML, but might be required because of some data or other requirements, you can follow your PreTransDal with the RunTriggers rule and get additional forms. (This is why I said not to add triggers to the forms that you know will come in by XML definition. Otherwise you might get them twice.)
I just add the no.of forms to the formset without adding any triggers to the form.
And i used PreTransDAL to trigger the forms.
Now i'm getting the order of the forms as it comes in the XML irrespective of the order of Forms in Formset.
But If i add the trigger to forms i mean calling the DAL for triggering the forms,
Now as you mentioned is printing twice as same as the order in the XML.
So finally i understood like "If we need to control the order of forms in the formset we can go for *PreTransDAL* but
sametime we need to make sure that we didnt add triggers to the forms in the formset".
I think you said that correctly. If you know the form is one that has to be named in the XML then you would not add a trigger in the Forms List for that form, but would instead rely upon the PreTransDAL to add it.
Although... It did occur to me just now that you might be able to have the form with a trigger defined in the group as well. You would just need your trigger script to do a HAVEFORM() check before deciding to do anything else. So, the start of your trigger would do something like this.
x = SrchData(".....
The HaveForm() would check to see if the form is already in the document set. If it is, then you can assume that you don't need to add it again. (This is assuming that you don't need duplicate copies of the form.)
If the form is not already in the document set, then you could do the remainder of any data checks you want in order to decide if you need to add the form. However, if the trigger adds the form, then you know it will occur in the order that the Forms List (GRP) defines.
But if I was relying upon the Extract XML to give me the forms and the order, I probably would just omit the triggers and be done with it. I only offer this other information in the event you have other special situations to think about.