Corticon process duration time

Posted by kdv@iap.de on 16-Dec-2016 08:26

Hi everybody,
is there possibility to send back the process duration time to the caller ?

Klaus

Corticon - Forum

All Replies

Posted by James Arsenault on 16-Dec-2016 08:29

Klaus,

By "process duration time" do you mean the time it took for a call to a decision service to be processed?

Jim

Posted by kdv@iap.de on 16-Dec-2016 08:34

Yes

Posted by Thierry Ciot on 16-Dec-2016 09:23

When you invoke the Corticon service from Rollbase we pass you back the call duration time.

Thierry.

Posted by kdv@iap.de on 16-Dec-2016 09:45

Hello Thierry,

do you mean with Rollbase the new Corticon console or is there a special API call ?

We have our own test program for a load test  

Klaus

Posted by Thierry Ciot on 16-Dec-2016 09:53

I mean that the duration of the call is tracked by Rollbase and is thus available within the Rollbase trigger.  It is not in the Corticon console.

Thierry.

Posted by Thierry Ciot on 16-Dec-2016 09:55

You can check www.progress.com/.../rollbase-the-first-low-code-platform-with-decision-services for an intro to using Corticon from Rollbase.

And www.progress.com/.../business-rules-pdf-editing-and-more-in-rollbase-44 as well.

Thierry.

Posted by kdv@iap.de on 16-Dec-2016 09:56

I have  a self written Java program . We are not working with Rollbase

Klaus

Posted by mparish on 16-Dec-2016 10:48

You could create a Corticon extended operator like this to get the time at the start and at the end of execution inside Corticon.
Then Corticon can calculate the overall execution time (or the execution time of any part of the rule flow.
The built in “now” operator in Corticon always returns the same value throughout the execution of the rules so that can’t be used for this purpose.
public class Utility implements ICcStandAloneExtension{
    public static BigInteger getMillis() {
       try {
           return BigInteger.valueOf(System.currentTimeMillis());
       } catch (Exception e) {
           return BigInteger.ZERO;
       }
    }
}
If you also record the start and end in your java program you can determine the overhead in making the call beyond just the execution of the rules.
 

Posted by Chris S. Hogan on 16-Dec-2016 11:30

Here is a detailed breakdown of two ways you can get timing information back for decision execution times:
 
###############################################################################################################
#  Specifies whether the Server Execution start and stop times are appended to the CorticonResponse document
#  after ICcServer.execute(String) or ICcServer.execute(Document) is performed.
#
#  Default value is false
###############################################################################################################
com.corticon.ccserver.appendservertimes=false
 
*** The description for this property only states that the execution start and stop times will be appended.  This description is pretty outdated.  Many more metrics will be added to the CorticonResponse than just those two numbers.
 
Now, by setting this property to “true” on the CcServer, this means that every execution will append the execution values to the CorticonResponse.  Just in case the customer doesn’t want all this information in every CorticonResponse, you can set an Attribute in the CorticonRequest to append the execution times for just that execution while keeping the above property set to “false”.  You do have that option.
 
<CorticonRequest xmlns="urn:Corticon" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" decisionServiceName="11COL_RECIPIENT-flow" addTimes=”true”>
 
Here is an example of what is returned in the CorticonResponse when the flag is set to true or the addTimes=”true”:
 
<CorticonResponse xmlns="urn:Corticon" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" decisionServiceName="11COL_RECIPIENT-flow" ccExeStart="1471979260789" ccExeStop="1471979265281" ccPreprocessPayloadStart="1471979260789" ccPreprocessPayloadStop="1471979261070" ccReactorWaitStart="1471979261070" ccReactorWaitStop="1471979261304" ccExecutionWaitStart="1471979261304" ccExecutionWaitStop="1471979261304" ccExecutionProcessStart="1471979261304" ccExecutionProcessStop="1471979265281" ccExecutionPreprocessStart="1471979261304" ccExecutionPreprocessStop="1471979261491" ccExecutionTranslationStart="1471979261491" ccExecutionTranslationStop="1471979263597" ccExecutionRulesStart="1471979263597" ccExecutionRulesStop="1471979265172" ccExecutionRulesPostProcessStart="1471979265172" ccExecutionRulesPostProcessStop="1471979265281" ccExecutionSuccessful="true" ccUnderutilizedExecution="false">
 
*** A little overwhelming…I know.  Here is maybe a better look at how things are broken down:
 
ccExeStart :: ccExeStop =Total Execution
ccPreprocessPayloadStart :: ccPreprocessPayloadStop =Preprocess Payload
ccReactorWaitStart :: ccReactorWaitStop = Reactor Wait
ccExecutionWaitStart :: ccExecutionWaitStop = Execution Wait
ccExecutionProcessStart :: ccExecutionProcessStop = Core Rule Processing
ccExecutionPreprocessStart :: ccExecutionPreprocessStop = Preprocess Execution
ccExecutionTranslationStart :: ccExecutionTranslationStop = Payload to CDO
ccExecutionRulesStart :: ccExecutionRulesStop = Rule Execution
ccExecutionRulesPostProcessStart :: ccExecutionRulesPostProcessStop = Post Process Execution
 
I do not breakdown the buckets in RED…I actually thought that would be too much detail.
 
Round Trip Execution
Transmission
Total Execution
 
Preprocess Payload
Reactor Wait
Execution Wait
Core Rule Processing
 
Preprocess Execution
Payload to CDO
Rule Execution
Post Process Execution
Logger
EDC (EntityManager)
EDC (commit/rollback)
Add RuleMessages to Response
Record Metrics
 
 
Christopher S. Hogan
Principal Systems Engineer
Progress
office
346-352-0699
mobile
646-243-4282
Twitter
Facebook
LinkedIn
Google+
 
 

This thread is closed