Automic Workload Automation

 View Only
Expand all | Collapse all

Best practises on one time/ad hoc changes of scheduled workflows/tsasks

  • 1.  Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 04, 2019 08:39 AM
    Hi,

    I am wondering if anyone else here has the same situation:

    Example:
    You need to set a break point in a scheduled workflow for any reason and afterwards you forget to remove the break point.

    I had it yesterday and it ended up that files were downloaded but not imported in the system because of the break point. We have a delay now of 3-4 hours.

    Is there any way/report to identify such cases?

    In my former company i've set up a report (different scheduling system "Redwood") which was checking if something in the workflow is different as in the initial setup. If so, a report was generated and sent in the afternoon.

    How do you deal those situations?

    Thanks in advance for your input.

    regards,
    Benedikt


  • 2.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 02:56 AM
    Hi There,

    To avoid unwanted delay, I guess you can set up MRT settings on the job plan if that runs more than a specific duration ( or x% above its estimated runtime ) it can shoot email alerts. I hope following documents maybe help. 

    MRT - https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/12.2/AWA%20Guides/help.htm#AWA/Workflows/wf_PropertiesPane_TimeDepsTab.htm
    CallOperator - https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/12.2/AWA%20Guides/help.htm#AWA/Objects/obj_notifications.htm?Highlight=call%20operator

    Regards,
    Prosenjit



  • 3.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 02:56 AM
    We use some kind of monitoring (select all active workflows in queue and compare their actual runtime with the average runtime for this workflow from uc4 plus 12 hours so not any shot workflow would alarm on a minimal runtime overdue).
    But that is not perfect as we have some (few) workflows that change their runtimes pretty often.

    On critical workflows with a known finishing time you can use the runtime overdue function in the workflow (or job) itself and let uc4 send you an email to inform for the overdue. We use this kind of "alarm" in a few workflows too.

    ------------------------------
    Administrator and Developer Jobautomation
    BNP Paribas S.A. Niederlassung Deutschland
    ------------------------------



  • 4.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 07:24 AM

    Hi,

    Thanks for your replies.

    Our process is running during the night and we have no 24/7 support.

    If the something is going wrong we will see it in the morning when we are starting to work.

    I just want to avoid such silly delays in the morning, by forgetting to enable for example the active flag again.

    The only thing i have in mind currently is in case of ad hoc / onetime changes to duplicate the workflow at let the "original" workflow untouched.

    But this is not really smart.

    regards,
    Benedikt




  • 5.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 08:23 AM
    Maybe you could a job to select the db-table eh for all hanging jobs and send this with email. This is maybe only smart then where not so many "normal" hanging jobs an the afternoon ;-)

    In a sqli-vara you could use this statement to select all jobs in the queue that have a breakpoint manually set in them:
    select ejpp_ah_idnr runid, ejpp_object jobname from ejpp where ejpp_status = 1562;

    Regards,
    Toni


    ------------------------------
    Administrator and Developer Jobautomation
    BNP Paribas S.A. Niederlassung Deutschland
    ------------------------------



  • 6.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 09:43 AM
    The GUI really needs to have a 'search for breakpoint' function.


  • 7.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:03 AM
    Hello,

    Here is a SQL Query to list all objects with a Breakpoint : 

    select oh.oh_name, oh.OH_Client, o2.JPP_Object select oh.oh_name, oh.OH_Client, o2.JPP_Object
    from oh,( select jpp_oh_idnr,JPP_Object  from JPP where JPP_Active in (2,3)) o2 where oh.OH_Idnr=o2.JPP_OH_Idnr

    ------------------------------
    OneAutomation Consultant
    ------------------------------



  • 8.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 08, 2019 10:29 AM
    ​I'll just leave this here ;)

    https://community.broadcom.com/ideation/allideas


  • 9.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:12 AM
    Hi,

    thanks again for your replies.

    The problem is that i need the information upfront. 

    When I get the information that the break point is set while executing the appropriate workflow -> its too late.

    My goal is, to get a report which shows me all workflows where a break point is set - i guess this is not working because those Information are collected/generated shortly before running the workflow or when the workflow is activated. -> am i right?

    regards,
    Benedikt




  • 10.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:21 AM
    Hello Benedikt,

    I use the previous SQL query I posted everyday, just before leaving my office, in order to be sure that I didn't forget a breakpoint in a workflow
    So you can set up a report with this query in order to attends your needs

    Regards
    Yohan

    ------------------------------
    OneAutomation Consultant
    ------------------------------



  • 11.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:26 AM
    Edited by Benedikt Weiler Jul 05, 2019 10:26 AM
    HI again,

    I've set a break point (see picture below)


    Afterwards i've executed your query. Result set is empty. 
    This workflow is scheduled in a scheduling object.
    We are using AE 12.1.1

    regards,
    Benedikt


  • 12.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks
    Best Answer

    Posted Jul 05, 2019 10:33 AM
    Hi

    here is an SQL (ORA) for AE V11.2- 12.2 which lists all objects in Worflows with(out) Breakpoint and (in)active in a client.
    just modify client number 0001 to your needs.

    select OH_NAME as "Workflow", JPP_OBJECT as "OBJ in WF", JPP_Lnr as "POS in WF", (CASE WHEN JPP_ACTIVE = 0 then 'not active, no breakpoint' WHEN JPP_ACTIVE = 1 then 'active, no breakpoint' WHEN JPP_ACTIVE = 2 then 'not active, with breakpoint' WHEN JPP_ACTIVE = 3 then ' active, with breakpoint' END) as "Active/Breakpoint" from OH, jpp
    where OH_IDNR=JPP_OH_IDNR
    /*
    JPP_ACTIVE:
    0 ... not active, no breakpoint
    1 ... active, no breakpoint
    2 ... not active, with breakpoint
    3 ... active, with breakpoint
    */
    and JPP_ACTIVE <> 1
    and JPP_OBJECT not in ('START','END')
    and oh_client = 0001
    and oh_deleteflag = 0

    cheers, Wolfgang

    ------------------------------
    I know I do really know it!
    ------------------------------



  • 13.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:38 AM
    It's strange
    This query works on both v11.2  and 12.2 for me

    For example, I just created a JOBP with a JOBS set with a breakpoint : 
    bk1
    The query will show me this object : 
    sc2

    ------------------------------
    OneAutomation Consultant
    ------------------------------



  • 14.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:43 AM

    Hi,

    did you activate/execute the JOBP?

    If I set a break point on an JOBS and i start the JOBP the query is returning a result.

    But if i set a break point, execute the workflow and remove the break point in process monitoring to continue the workflow, the query is returning no result afterwards.

    And if you then forget to remove the break point in the workflow -> next scheduled execution job will hold again.

    regards,
    Benedikt




  • 15.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:52 AM
    Hi,
    I have overseen the post from Wolfgang. This query is working.
    Thanks a lot - makes our life lil bit easier :-)

    regards,
    Benedikt


  • 16.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 05, 2019 10:58 AM
    Hi 

    welcome :-)
    we developed this SQL for colleagues who often work with breakpoints and had the same issue- they forgot:-)
    they have a  scheduled CALL object that sends an HTML email with the result of the SQL (VARA) daily.

    the easiest solution for this (if possible!) let the Workflow generate and set the breakpoint in Worflow monitor (= for this execution only).
    precondition: the WF must be generated/activated so far...

    Plan B: Remnder in outlook :-)

    cheers ,Wolfgang

    ------------------------------
    I know I do really know it!
    ------------------------------



  • 17.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 08, 2019 05:29 PM
    We use Plan B: Reminder in Outlook

    If you have a breakpoint setting that needs to be toggled regularly, then I would consider engineering automation around that requirement so that staff are not expected to manipulate the production code.  You could set up a solution that only requires the manipulation of a setting in a variable.  Precondition rules would then use that variable to decide to either run the task with the breakpoint, or the task without the breakpoint.  Depending upon the use-case, the variable could be automatically reset as well so you can set it and forget about it.


  • 18.  RE: Best practises on one time/ad hoc changes of scheduled workflows/tsasks

    Posted Jul 09, 2019 02:13 AM
    You can set breakpoints using AE Script. 

    In the past I had to manage large workflows where it wasn't easy to find tasks that have been breakpointed. So I introduced a SCRI object (without generate-at-runtime) as the immediate successor right after the <START> object and predecessor of the following logic. The SCRI object did a lookup on a SQL.VARA to identify, whether breakpoints have to be set or not. The objects can be designed in a way, that they are completely reuseable without doing any configuration on them.

    This system can be used to also do in-activation and also to do vice-versa settings (i.e. activate inactive tasks). From my experience I can say this works as a charm and operations loved it. With the power of the Vara you might introduce even more settings (like do only set breakpoints on specific calendar-conditions).

    Pseudocode incoming:

    VARA.BREAKPOINTS
    <object or lnr> | <date> | <true/false>

    VARA.SQL.BREAKPOINTS
    <query that joins VARA.BREAKPOINTS with JOBP-Tasks and Returns all lnr's that must receive manual-hold>

    SCRI.STOP
    process VARA.SQL.BREAKPOINTS
      if workflow is not stopped - stop it
      modify Task
      optional: send mail
    end process
    if workflow has been stopped - start it

    ------------------------------
    Swisscom & WorkflowCommander
    ------------------------------