Endevor

  • 1.  Switching Endevor Webhooks on and off

    Posted Jun 21, 2018 08:27 AM

    For Endevor element and package actions that can be logged via webhooks

    https://docops.ca.com/ca-endevor-SCM/18-0/en/installing/activity-logging-for-webhook-support

     

    When is the control point initiated?

    As the turn on/off and SCL are stored in a PDS, when do the options come into effect across my Endevor instance?

    Is it per user or per instance? What happens to inflight work like batch jobs and packages that are running at the time of a change to the variables?



  • 2.  Re: Switching Endevor Webhooks on and off
    Best Answer

    Posted Jun 21, 2018 08:36 AM

    Hi Steve, 

     

    I found a lot of the Webhooks documentation is under ALC, I've asked CA to move these to under Common Services. Logging is done per instance not per user. Generally you'd leave the logging always on and then enable/disable the Webhooks via the Webhook configuration page in your browser. 

     

    From what I can tell the E2ELOG parm member is validated prior to an action and logging is done when the action is complete, hopefully someone from CA can confirm. 

     

    If you've not already please vote for the 'Multiple To Locations for E2ELOG member' ideation from Bernie, it's a real gap in the Webhooks - 

     

    Multiple TO Locations for E2ELOGMBR 

     

    Cheers,

     

    Ed



  • 3.  Re: Switching Endevor Webhooks on and off

    Broadcom Employee
    Posted Jul 23, 2018 06:08 AM

    C1DEFLTS parameter E2ELOGMBR value is stored in endevor control blocks during endevor initialization by program BC1PINIT.

     

    This happens at the start of the ISPF endevor or QE dialog, at the start of any batch utility like C1BM3000, or at the start of an STC spawned at the request of CAP, workbench or Web Services. Note that, in the case of Web Services, the use of STC pooling has an effect on this since endevor initialization happens at the start of the STC.

     

    If the member name was specified, it is read and parsed at the end of the first element or package action performed during the endevor run, right before the point where any defined user exit 03 would be called or, for package actions, after any defined "after package action" user exits would be called. If the member parses without error, then E2E logging is performed for the action as specified in the member.

     

    The E2ELOGMBR member is not parsed again during the same run. Subsequent element or package actions are logged at the same spots using the definitions parsed at the completion of the first action.

     

    This is how our programs are written as of today.

     

    Hope this helps

    Eduard Penafiel

    CA-Endevor support