Corticon process duration time - Forum - Corticon - Progress Community

Corticon process duration time

 Forum

Corticon process duration time

This question is not answered

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

Klaus

All Replies
  • Klaus,

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

    Jim

    James Arsenault  |  Product Development  |  Progress Software
    email: james.arsenault@progress.com |  direct: 781-280-4934

  • Yes

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

    Thierry.

  • 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

  • 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.

  • 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.

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

    Klaus

  • 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.
     
  • 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+