AppWorx, Dollar Universe and Sysload Community

 View Only
  • 1.  Problems Using AE Object JOBG in AE-Actions

    Posted Jun 26, 2019 10:14 AM

    Hello Community,

    we have several problems using the jobg object in Actions.

    Our requirement

    • Jobs are executed parallel within an action.
    • The number of parallel jobs is determined dynamically at runtime.
    • You can react to the end status of the jobs in the action.

    We currently use job groups for this purpose.

     

    Action examples in which we currently use job groups

    • Stop/start of queues during maintenance of a target system
      • The target system can be connected to several AE clients.
      • The Job for stopping/starting the queue is started for each AE client.
      • Jobs are executed simultaneously.
    • Execute R3 report with several variants at the same time:
      • R3-Job is started for each variant.
      • R3-Jobs should be executed simultaneously.

     

    Problem

    We activate the same action multiple times in different processes, sometimes at the same time. A job group cannot be started more than once at the same time, therefore the workflow is canceled.

     

    Our Workarounds

    Variant 1:

    - Workflow that contains a job group is set to "max. parallel 1".

     

    Variant 2 (example is attached):

    - The action-specific job group in workflow is replaced at runtime by process-specific job group.

    - The action-specific job group in the workflow only serves as placeholders.

    - The action workflow is modified at runtime: Action-specific job group is replaced by process-specific job group.

    - This only works as long as the process in which the action is used is not started multiple times at the same time.

     

    Is there another solution for our requirements or are job groups the right choice? How can we solve our problems with job groups?

    Thank you !

    Best Regards
    Heiko Schmider



    ------------------------------
    dmTECH GmbH
    Team Business Automation
    Phone +49 721 5592-2622
    E-Mail:heiko.schmider@dm.de


    ------------------------------


  • 2.  RE: Problems Using AE Object JOBG in AE-Actions

    Posted Jun 27, 2019 01:59 AM
    I did not 100% understand your issue. What I understood is, that you have a complex ressource management scenario. Did you try SYNC objects? They allow complex setups (that's good and bad at the same time) and there are also AE script elements that interact with them. If you need to manage ressources over several clients (Mandanten) you might go for CallAPI or better REST (V12.1+).


  • 3.  RE: Problems Using AE Object JOBG in AE-Actions

    Posted Jun 27, 2019 03:47 AM

    Hello Joel,

     

    Thank you for your reply.

     

    Our intention is to build all functions that we use in modules, that can be reused without any limit. (Automic Actions).

     

    We used the jobg in the past for activating R3 Jobs "parallel" at the same time. With jobg we had / have the control over the

    execution status  of the activated jobs, that be started in den JOBG. As the JOBG is  member in den JOBP – the JOBP sends us response if one of the parallel

    started R3 Jobs has an status, that is not ended_ok.

     

    We have only the problem by using the jobg in Automic Action model. The error we get: "Jobg can be started only once at the same time"

     

    We have taken the first workaround in our Action and used for each business Process his own jobg. In Prompt Parameter of the action we have the input parameter

    for the JobG – and the Action will replace the JOBG by runtime with the jobg of the Business Process. (The jobg must be created manuell for each BP)

     

    Now we have a new constellation.

     

    The customer starts the same R3 BP several times at the same time with different filters on the variants.

     

    Now we get already the problem "JOBG can be started only once at the same time"

     

    I will explain, that we have also an workaround that jobg can be used in action for several business processes – but we have now the problem if on BP will be started more at once at the same time.

     

    I hope you will understand my explanation !

     

    Regards

    Heiko

     

     


    dmTECH GmbH
    Carl-Metz-Str. 17, 76185 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
    Telefon 0721 5592-2500 Telefax 0721 5592-2777
    dmTECH@dm.de * www.dmTECH.de
    GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
    Geschäftsführer: Erich Harsch, Martin Dallmeier, Roman Melcher






  • 4.  RE: Problems Using AE Object JOBG in AE-Actions
    Best Answer

    Posted Jun 27, 2019 09:17 AM

    Okay got it. Cool case actually.

    What about having some JOBG objects in reserve? Before activating the objects, determine a free JOBG object to assign. 

    The reservation process could involve SYNC objects to make sure, that no race conditions happen. You might do a SYNC for each JOBG ressource with an incrementing ressource number:

    JOBG_1
    SYNC_1
    JOBG_2
    SYNC_2
    (…)

    Each SYNC has two states (FREE / RESERVED) and two actions:
    - Reserve (if state is FREE set state to RESERVED)
    - Release (if state is RESERVED set state to FREE)

    When determining a free ressource, proceed like this:
    set search = 'y'
    set counter = 0

    while search = 'y'
      if object sync_(counter) exists:
        set-sync-action 'reserve' on sync_(counter)
        if set-sync-action was successful:
          set search = 'n'
        else
          set counter = counter + 1
        endif
      else
       <fail as all available JOBG are in use>
      endif
    endwhile

    ! counter contains the free jobg resource. At this point, no other process can reserve the ressource since the sync
    ! action is not executeable anymore
    activate_uc_object with identified jobg 
    activate_uc_object with identified jobg with WAIT FOR END
    set-sync-action 'free' on sync_(counter)

    That should do the trick. Happy hacking! Or let me know if some of the above does not meet your requirements ;-).