I am documenting our Dashboards and BAQs by adding some user notes into the description field along with the date so that we can see when the customization was last visited.
I am now moving onto documenting the Data and Method Directives, but I don’t see any description box for the individual pre/post processing entries. Is this expanded in later versions? (we are on 10.2.100.15).
If not, is there a common practice to document the who/what/why for these pre/post processing directives?
See
That’s helpful! I’ll probably use that for some of the history and additional details.
I suppose I was looking for a field-level description with hopes the ERP Analyzer would spit it out to quickly evaluate customizations during upgrades.
Currently we are doing Revision control at the group level. It’s my thought process that at the BO.Method level and the Table.Field level that these can possibly effect the others on the same object so changes in one should vet out the others and they get stored in Bitbucket at a group and deployed as a group. If you have some sort of DevOps going on these would typically tie back into tickets or whatever project management system you are employing (i.e. Agile, BDUF etc). Further documentation is done in the little comment fields provided on the widget, but most is done on the user story regarding design and intent. Probably not super helpful for the ERP Analyzer though.
The BPM Name that you apply does show in any trace logs, so you could also apply a version number to the end of the BPM Name… you just need to make sure that when transitioning from Dev to Live environments, that you always disable the old version number.
But by also adding the version number to the name, you could compare the two versions in the trace logs (run separately of course) to see if any timing differences need to be addressed.
One additional trick I thought about was to put a calculated field “BAQVersion” on the top level of the BAQ that holds the BAQ Name & version number. This field could be hidden in any dashboards that use them, (but could be later exposed).
Another trick on UI Customizations that I like to utilize is to put a LABEL at the bottom left corner of the UI that tells the custom name/version. This way, you can see that it was customized without digging.
In Product Configurators, I like to change the Page description field to show the current rev of that configurator design. This really helps to prove that you are running the correct version after you deploy it to live and/or EWA/ECC.