Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only
  • 1.  Run asynchronous tasks from automation scripts (new in 7.6.1.2?)

    Posted Sun August 09, 2020 12:16 AM
    Edited by System Admin Wed March 22, 2023 11:46 AM
    New in 7.6.1.2:

    "You can add scripts that can run as asynchronous jobs in the product. Use the asynchronous job framework to submit jobs that need to be run one time asynchronously, such as when you want to run something quickly in the background."
    Adding scripts that run as asynchronous jobs

    What would be an example of a use case of this?




    #Maximo
    #AssetandFacilitiesManagement


  • 2.  RE: Run asynchronous tasks from automation scripts (new in 7.6.1.2?)

    Posted Sun August 09, 2020 01:47 AM
    Hi,

    Asynchronous jobs are mostly used to run a task in the back ground. User click on some action from UI which triggers an Asynchronous job (similar to cron tasks). One example of this would be to create Purchase requests for the list of Planned Materials. So, user click on an action saying generate PO from Work Order. This action triggers an Asynchronous task which run in back ground to create requests from the planned material. User does not have to wait for the task to complete to work on other work orders or do other jobs. The asynchronous task will create the PRs and send an email or add it to start center query( or work center). 
    This is one example and there can be a number of scenarios. The only different between this and escalations/cron task is escalations/cron task will always run even if user has not processed any new records but asynchronous job will run only when a user action is performed.
    This was achieved by creating Java threads  and it is now available from auto scripts.
    I haven't used this auto script so I can't dig deep into any other specific feature Maximo auto script bring into this. 
    A Maximo technical architect/ consultant can help you decide which would be the preferred way to achieving back ground task.

    ------------------------------
    Biplab Choudhury
    Maximo Consultant
    Tata Consultancy Services
    Melbourne
    ------------------------------



  • 3.  RE: Run asynchronous tasks from automation scripts (new in 7.6.1.2?)

    Posted Mon August 10, 2020 07:55 AM
    This was my RFE so I can give a bit of a background on why we requested it after we built our own java class handler. As Biplap mentions, the big difference between a standard cron task and an asynchronous job is that the user is choosing to do an action on a record/set of records. Out of box there are quite a few scenarios where IBM already utilizes async jobs, such as changing status in the background, generating PM work orders in the background, etc. The user chooses which records to take the action on, and by choosing to do it in the background, they're not stuck waiting for it to complete. 

    This allows you to ensure these background tasks aren't running on the UI JVM. If these processes are resource intensive in WebSphere, it can negatively impact the experience for your other users who were on that JVM/server. 

    This allows your users an easy way to schedule an activity. It's not clear to me yet with the IBM implementation if this is the case (as they use a non-persistent object to create the job that doesn't have a way to set the date), but asynchronous jobs can typically be scheduled so it runs when you want it to run. This is important if you need something to run at a user defined time as you don't want to build manual cron task instances. 

    And finally, it allows you a framework to ensure only 1 of your processes is running at once. As an example of where this might matter is we built a custom asset rollup process to replace the out of the box report. With an async job, we can ensure only one of those processes will run at any given time (which avoids an issue with record contention that you'd see with standard rollup report). You'd also get this with a cron task instance, but again, if your users need to be able to invoke that process there's not a good way to limit it otherwise without using some sort of locking mechanism that you'd have to maintain.

    ------------------------------
    Steven Shull
    Director of Development
    Projetech Inc
    Cincinnati OH
    ------------------------------