Automic Workload Automation

  • 1.  How to activate a job in a different client through callAPI

    Posted Jul 13, 2016 08:20 PM

    *This is assuming you understand what callAPI is and you have it setup
    *This is a simple example. You can test/create a more complex setup and script.
    CallAPI documentaton can be found here: http://docs.automic.com/documentation/AE/11.2/english/AE_WEBHELP/help.htm?product=awa#ucacif.htm?Highlight=callapi


    While objects are restricted within the client it's created on, there is a way to activate (and more) a job that is in another client. Here's a simple test that you can do:

    1) on client 200, create a job  (eg: windows job JOBS.WIN.200)
    2) create a text file that activates JOBS.WIN.200 (eg: script.txt)
    :set &VAR# = activate_uc_Object(JOBS.WIN.200)

    3) on client 100, create a job (eg: windows job JOBS.WIN.CALLAPI) that will call script.txt via callAPI
    UCXBXXXC SCRIPT=C:\CALLAPI\script.txt LOGON=98, SMITH, AE INI=C:\CALLAPI\BIN\ucxbxxxc.ini

    Note: UCXBXXXC SCRIPT={path and name of the script file}  LOGON={client, user, department, password  INI=ini file}

    If you have updated ucxbxxxc.ini with the client, user, password, etc then you can skip the LOGON and just use:
    UCXBXXXC SCRIPT=C:\CALLAPI\script.txt

    4) check if the job in client 100 ended_ok
    5) check if the job in client 200 was triggered and ENDED_OK. The job JOBS.WIN.200 should now have at least one entry in the Statistics window. 


  • 2.  How to activate a job in a different client through callAPI

    Posted Jul 05, 2017 04:07 PM

    *This is assuming you understand what callAPI is and you have it setup
    *This is a simple example. You can test/create a more complex setup and script.
    CallAPI documentaton can be found here: http://docs.automic.com/documentation/AE/11.2/english/AE_WEBHELP/help.htm?product=awa#ucacif.htm?Highlight=callapi


    While objects are restricted within the client it's created on, there is a way to activate (and more) a job that is in another client. Here's a simple test that you can do:

    1) on client 200, create a job  (eg: windows job JOBS.WIN.200)
    2) create a text file that activates JOBS.WIN.200 (eg: script.txt)
    :set &VAR# = activate_uc_Object(JOBS.WIN.200)

    3) on client 100, create a job (eg: windows job JOBS.WIN.CALLAPI) that will call script.txt via callAPI
    UCXBXXXC SCRIPT=C:\CALLAPI\script.txt LOGON=98, SMITH, AE INI=C:\CALLAPI\BIN\ucxbxxxc.ini

    Note: UCXBXXXC SCRIPT={path and name of the script file}  LOGON={client, user, department, password  INI=ini file}

    If you have updated ucxbxxxc.ini with the client, user, password, etc then you can skip the LOGON and just use:
    UCXBXXXC SCRIPT=C:\CALLAPI\script.txt

    4) check if the job in client 100 ended_ok
    5) check if the job in client 200 was triggered and ENDED_OK. The job JOBS.WIN.200 should now have at least one entry in the Statistics window. 


    Hello  Christine Chavez,

    I was going thru your example "How to activate a job in a different client through callAPI".
    In my scenario to access both the clients (in the DEV environment): Name, Department, Password are same except the client.
    I have a job LINUX_SECURITY.JOB in one client 900 and I have a workflow on client 400, towards the end of the workflow on Client 400 (after 10th job out of 12 jobs in the workflow) I would like to trigger the existing job
    LINUX_SECURITY.JOB on Client 900, once complete, continue with the 11th job in the workflow of client 400.

    By going thru your example, my doubt is: would the script.txt contain ":set &VAR# = activate_uc_Object(
    LINUX_SECURITY.JOB)" on the AE host in a location. 

    Also what are the values for *** in UCXBXXXC

    Could you validate if I am right or not?

    Thanks,
    Ram.




  • 3.  How to activate a job in a different client through callAPI

    Posted Jul 06, 2017 02:47 AM
    Hi

    Yes thats right - the automic scriptfile is usually located in the call api directory. the only precondition is that it must be located on the server (or net drive) on which the call api is started - so the callapi binary must have access to it.