Hello guys,
In SoftwareAG document "REPORT SCRIPTING - BEST PRACTICES" , it is written in bold in the introduction :
"Completed reports should always be tested on their memory performance and quality"
But how can you , as a report programmer with no access to the Aris server, test the memory performance of a script ?
Thanks
MB
I'm someone that does have access to the ARIS servers I'm writing reports for and to be honest the access doesn't matter in regards to testing memory performance. The ARIS server does so many things at any given moment that figuring out whether memory/CPU usage spikes stem from your report or some some other component (we also run Aware and ARCM on the same server) is practically impossible.
The way you go about this is think about what your report does from an algorithm point of view and what's going on in between the ARIS server and the database server.
For example, you want to list the names of all object definitions on an ARIS database:
A bad way to go about it (although it's the intitive way) would be:
- get the root group of the database
- recursively search all object defintions contained in this group (even if you just use the bRecursive flag with a single ObjDefList call on the root group)
- iterate through the object definitions and ask for the AT_NAME, attribute of each object
This is bad because
- the recursive search concerns itself with group structures which don't matter for our task
- requesting the name attribute object after object leads to an incredible amount of talking between the ARIS server and database server.
The good way to go about this is:
- use the database Find method to search for all object definitions
- pass that list of object definitions to the database ItemAttrMap method to fetch all required AT_NAME attributes in one go
- then either iterate through the object definitions and look up the required attribute via GUID in the HashMap result of the ItemAttrMap, or just iterate through the entries of the ItemAttrMap HashMap directly.
If you chech the algorihm time and space complexity, clean up after yourself (release no longer needed references, as described in the best practices document) and attempt to minimize the amount of talking between the ARIS server and database server by using methods that bundle what would be multiple requests into a single request whenever possible, you should have absolutely no problem writing very efficient reports.
