Adding checkpoints to your code is useful when coretime indicates a long lag between two Studio Customization Toolkit calls. For instance: 11:37:09.941 t@23: 1973 milliseconds: ADK: evaluateSelect.bosQuery 11:39:21.921 t@23: 2 milliseconds: ADK: open.bosBusinessObject 11:41:23.347 t@23: 2 milliseconds: ADK: open.bosBusinessObject After the checking corresponding verbose log entries to verify that these two Studio Customization Toolkit calls are from the same session, we see that for some reason, the Studio Customization Toolkit client is taking over two minutes after the BusinessObject query before it issues the next Studio Customization Toolkit call to open a business object, and then another two minutes until the next open. The developer can add checkpoint text in the logic between the expand and the open to help determine what is taking so long. If the source page for the query is not known, the trace should be reproduced with Studio Customization Toolkit Origin Trace enabled (refer to the "Server Diagnostics" chapter of the PLM Platform Installation Guide). The developer must decide how to place the checkpoints in a way that shows where the processing time is going. There should be a checkpoint added at the start of and end of each suspicious non-3DSpace function. For instance, the context.printTrace() calls in the code below were added as checkpoints. StringList resultSelects = new StringList(1);
resultSelects.add("name");
matrix.db.Query query = new matrix.db.Query("EmployeeQuery");
query.open(context);
query.setObjectLimit((short)100);
query.setWhereExpression("attribute[Host Meetings]~~\"Yes\"");
BusinessObjectWithSelectList bosWithSelect = query.select(context,resultSelects);
if (debug) System.out.println("query returned " + bosWithSelect.size() + " objects");
for(int j=0; j<bosWithSelect.size(); j++)
{
BusinessObjectWithSelect bows = bosWithSelect.getElement(j);
String name = (String)(bows.getSelectDataList("name")).elementAt(0);
System.out.println("person = " + name);
context.printTrace("VERB", "Start checkpoint: ldap lookup for " + name);
LDAPTool ldapResult = LDAPTool.lookup(name);
context.printTrace("VERB", "End checkpoint: ldap lookup for " + name);
context.printTrace("VERB", "Start checkpoint: meeting verify for " + name);
MeetingMinder meetingResult = MeetingMinder.verify(name);
context.printTrace("VERB", "End checkpoint: meeting verify for " + name);
BusinessObject bo = new BusinessObject("Person", name, "-", "eService Administration");
bo.open();
.
.
}
Analysis of the coretime output generated from the verbose log corresponding to this code (below) shows the LDAP lookup is what is consuming most of the lag between the query and the open. Note the long run time of the checkpoint for "ldap lookup for asmith". 13:12:45.909 t@2260: 1198 milliseconds: ADK: evaluateSelect.bosQuery 13:12:47.107 t@2260: 0 milliseconds: ADK: printTrace.bosContext 13:12:47.107 t@2260: 118014 milliseconds: CHKPT: ldap lookup for asmith 13:14:45.121 t@2260: 0 milliseconds: ADK: printTrace.bosContext 13:14:45.121 t@2260: 0 milliseconds: ADK: printTrace.bosContext 13:14:45.121 t@2260: 15 milliseconds: CHKPT: meeting verify for asmith 13:14:45.136 t@2260: 0 milliseconds: ADK: printTrace.bosContext 13:14:45.136 t@2260: 0 milliseconds: ADK: open.bosBusinessObject | |||||||||||