Maximo

Maximo

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

 View Only
Expand all | Collapse all

Determine if WO was created from a scheduled PM -or- manual PM action?

  • 1.  Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Sun May 09, 2021 02:50 PM
    MAM 7.6.1.2:

    I have WOs that I know were created from a PM  (since WORKORDER.PMNUM is populated).

    Is there a way to determine how the workorders were generated (via the PM)?
    A) Automatically created from a scheduled PM / pmwogen
    or B) Manually created via the Generate Work Order action

    Thanks.
    #AssetandFacilitiesManagement
    #Maximo


  • 2.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Sun May 09, 2021 02:59 PM
    Edited by System Admin Wed March 22, 2023 11:50 AM
    Is it as simple as looking at the REPORTEDBY field?
    • If REPORTEDBY='MAXADMIN', then scenario A (WO was automatically created from a scheduled PM / pmwogen)
    • If REPORTEDBY=<specific user>, then scenario B (WO was manually created via the Generate Work Order action)

    Or are there exceptions to consider?





  • 3.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Mon May 10, 2021 08:02 AM
    Just that simple.

    ------------------------------
    John Rice
    ------------------------------



  • 4.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Mon May 10, 2021 02:19 AM
    Hi User1971,

    My base question is why?  Both scenarios go through the same work order generation process.  I have never come across your requirement, so highly interested in the background.

    ------------------------------
    ===============================
    Craig Kokay,
    Lead Senior Maximo/IoT Consultant
    ISW
    Sydney, NSW, Australia
    Ph: 0411-682-040
    =================================
    #IBMChampion2021
    ------------------------------



  • 5.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Mon May 10, 2021 08:06 PM
    Edited by System Admin Wed March 22, 2023 11:44 AM
    @Craig Kokay
    I have a weird issue where my scheduled PMs (large WO hierarchies) sometimes run twice, and are sometimes missing child WOs.

    There should be 1683 child WOs in every WO hierarchy -- since there are 1683 route stops in the route. And the PM should only run once per day:

    I had wondered if the PM had been manually run via the Generate Work Order action in some cases -- which would have explained the duplicate WOs. But I realized after posting this question that I could just query WORKORDER.REPORTEDBY='MAXADMIN' to only get the WOs that were automatically generated/scheduled. So it looks like all those WOs were created automatically by the system. So I'm not sure what's going on.

    For what it's worth, here is the source query for the resultset above:


    --query was updated 2021-05-20

    --p = source is parent WO records --pm = source is PM records --c = source is child WO records select to_char(p.reportdate, 'MONTH DD') as p_reportdate_day, p.wonum as p_wonum, p.pmnum as p_pmnum, p.route as p_route, p.reportdate as p_reportdate, -- pm.pmcounter as pm_counter, pm.targstarttime as pm_targstarttime, -- pm.nextdate as pm_nextdate, c.parent as c_parent, c.pmnum as c_pmnum, c.route as c_route, c.wo_count as c_wo_count, c.min_reportdate as c_min_reportdate, c.max_reportdate as c_max_reportdate, c.processing_time_hrs as c_processing_time_hrs from (select * from maximo.workorder where pmnum like 'BC%' and reportedby = 'MAXADMIN' and istask = 0) p left join maximo.pm pm on p.pmnum = pm.pmnum left join ( select parent as parent, pmnum as pmnum, route as route, max(reportedby) as max_reportedby, count(*) as wo_count, min(reportdate) as min_reportdate, max(reportdate) as max_reportdate, round((max(reportdate) - min(reportdate)) * 24,1) as processing_time_hrs from maximo.workorder
    where
    istask = 0 group by parent, pmnum, route, changeby order by min_reportdate desc ) c on p.wonum = c.parent order by p.reportdate desc

    .
    I'll admit that I'm new to PMs though, and have probably been staring at this for too long. I've likely just made a silly mistake somewhere.

    Cheers.


    #AssetandFacilitiesManagement
    #Maximo


  • 6.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Tue May 11, 2021 02:46 AM
    So, I still not sure that the query is correct.  I like your style I like your style of query though my brain says, nope.  I'm thinking that you have not excluded task work orders.

    There should be no way for a PM to be run twice by a cron task, by that, I mean the PM once generated should no longer be eligible until it reaches the next frequency unit.  This would be a tad easier if the PM counter was passed over as well.

    So run the below SQL using the theory that when a PM with a route is generated, there will always be parent work order assuming you have selected the option to generate as child WO rather than tasks.  Adjust as needed.

    SELECT WONUM, pmnum, ROUTE , reportdate,
    (SELECT count(*) FROM workorder w2 WHERE w2.parent = w.wonum AND w2.siteid = w.siteid AND istask=0) AS num_child
    FROM workorder w
    WHERE pmnum IS NOT NULL
    AND istask = 0;​

    Looking at your timestamp, one would assume that your work orders are not being manually generated.  Let's see what result you get now?



    ------------------------------
    ===============================
    Craig Kokay,
    Lead Senior Maximo/IoT Consultant
    ISW
    Sydney, NSW, Australia
    Ph: 0411-682-040
    =================================
    #IBMChampion2021
    ------------------------------



  • 7.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Thu May 13, 2021 05:25 PM
    Edited by System Admin Wed March 22, 2023 11:45 AM

    @Craig Kokay

    Thanks very much for your help. Since I don't have tasks in this test, your query is producing the same results as mine. So that's good. 

    Right now, I'm focusing specifically on the issue where child WOs are sometimes missing from the PM --> WO hierarchy... since that issue is easily reproducible. I'm in the process of investigating now.



    Here's one theory about what's happening:

    A colleague looked at the system logs, and says, "The new WORKORDER.PLUSSGEOJSON field in Maximo Spatial might be initializing when scheduled PMs are being run. The PLUSSGEOJSON functionality is calling the GIS web service for each WO that is being generated. So if the GIS service happens to be unreachable, then the PM will silently fail -- even though the PM has nothing to do with the GIS service."

    [5/13/21 1:55:43:051 EDT] 00000138 SystemErr R psdi.util.MXApplicationException: BMXAS0674E - Could not access url: .../arcgis/rest/services/Maximo/WO_TST/MapServer/25/query Error Message: java.io.IOException: Server returned HTTP response code: 503 for URL: .../arcgis/rest/services/Maximo/WO_TST/MapServer/25/query?f=json&where=WONUM%3D%27WO89127%27&returnGeometry=true&outSR=4326 [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.pluss.app.plussgis.helper.MapUtil.getContentFromURLbyGET(MapUtil.java:653) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.pluss.app.plussgis.helper.MapUtil.getContentFromURLbyGET(MapUtil.java:510) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.pluss.app.plussgis.helper.MapUtil.getJsonFromUrl(MapUtil.java:489) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.pluss.app.plussgis.PlusSGISService.getCoordsFromLinkedFeature(PlusSGISService.java:383) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.pluss.app.plussgis.PlusSGISService.computeGeoJSONFromMbo(PlusSGISService.java:675) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.pluss.app.PlusSFldGeoJSON.initValue(PlusSFldGeoJSON.java:53) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboValue.initValue(MboValue.java:410) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboValue.isNull(MboValue.java:520) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboSet.setBindValueAsClob(MboSet.java:9924) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboSet.setBindValue(MboSet.java:9562) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboSet.insertMbo(MboSet.java:8331) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboSet.saveTransaction(MboSet.java:7736) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.txn.MXTransactionImpl.saveTransaction(MXTransactionImpl.java:221) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.txn.MXTransactionImpl.save(MXTransactionImpl.java:156) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboSet.save(MboSet.java:7540) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.mbo.MboSet.save(MboSet.java:7464) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.workorder.WOSet.save(WOSet.java:1484) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.workorder.WO.doApplyRoute(WO.java:6471) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.workorder.WO.applyRoute(WO.java:6112) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.workorder.WO.applyRoute(WO.java:6092) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.pm.PM.generateWorkOrderInformation(PM.java:2705) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.pm.PM.wogen(PM.java:2115) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.pm.PM.generateWork(PM.java:1766) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.plust.app.pm.PlusTPM.generateWork(PlusTPM.java:303) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.pm.PMSet.generateWork(PMSet.java:186) [5/13/21 1:55:43:052 EDT] 00000138 SystemErr R at psdi.app.pm.PMWoGenCronTask.cronAction(PMWoGenCronTask.java:348) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at psdi.app.pm.PMWoGenCronTask.cronAction(PMWoGenCronTask.java:190) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at psdi.server.CronTaskManager.callCronMethod(CronTaskManager.java:2566) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at psdi.server.CronTaskManager.access$1100(CronTaskManager.java:106) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at psdi.server.CronTaskManager$CronThread.run(CronTaskManager.java:3476) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.util.concurrent.FutureTask.run(FutureTask.java:277) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:191) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [5/13/21 1:55:43:053 EDT] 00000138 SystemErr R at java.lang.Thread.run(Thread.java:811)



    That is consistent with what another colleague found:


    "It doesn't make sense to me the way they are doing it (PLUSSGEOJSON). I see that field class code and they are retrieving the x/y from GIS if the asset is linked but they do it every time the field is initialized. If GIS is down you get an error, or if you do a batch operation it will be slower because of these queries in GIS.
    And they are updating the asset with jdbc directly but it triggers the rowstamp update and that is why you see that error, because I guess you are on Oracle and rowstamps are updated by a trigger. I think I didn't see it because I am on SQLServer on my vm.

    I bet they did it on initialize to avoid needing to fix existing records.. instead of doing it on save and providing a way to update existing ones.

    In my case I just removed that PLUSSGEOJSON field from the ARCGISASSET object structure."



    Anyway, that's over my head for the most part. And it might warrant posting a separate question.

    But I just thought I'd post that in case it's of interest to anyone.

     


    #AssetandFacilitiesManagement
    #Maximo


  • 8.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Fri May 14, 2021 11:52 AM
    Edited by System Admin Wed March 22, 2023 11:56 AM


  • 9.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Mon May 10, 2021 08:02 AM
    You should be able to determine whether the Reported By field shows an actual UserID or whether it is the UserID of the process running WOGEN.  For example, all of our PM generated WOs created by WOGEN start with:  MAXWOGEN.

    ------------------------------
    Wayde Prejean
    Manager IC - OPS
    Kinder Morgan, Inc.

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



  • 10.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Tue May 10, 2022 10:59 AM
    Is there a way to determine whether a WO is generated from PM(Generate WO action or PMWOGEN Cron task) or it is created from Integration or Conversion?
    Is there any specific field apart from PMNUM?

    ------------------------------
    Chinmaya Kore
    ------------------------------



  • 11.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Tue May 10, 2022 11:18 AM

    We show who created the work order, and for work orders generated by WOGEN, we have unique IDs.  So, if the work order has a PM number and the CreatedBy is not one of our special WOGEN IDs, we know it was manually generated.  Otherwise, if it has one of the WOGEN IDs, it was created during our morning WOGEN run.

     

    Thanks,

    Wayde J. Prejean

    Kinder Morgan Inc.

    Manager IC-Ops, Maximo Coordinator

     






  • 12.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Tue May 10, 2022 11:47 AM
    Thank you for the reply, Is there a way wherein we can write a custom logic using automation script on the "Generate Workorder" action and PMWOGEN Cron task?
    Like with the existing logic of the action and the cron we need to add our custom logic. We cannot write on WO save,It should only be triggered on when WO is generated from PM.

    ------------------------------
    Chinmaya Kore
    ------------------------------



  • 13.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Tue May 10, 2022 12:17 PM

    This is from Jason Luke, my I.T. Lead here at Kinder Morgan Inc.

     

    I like where you were going. 

     

    You could create an automation script that is an Object Launch Point and have it only occur on Add where the condition is checking who created and that the pmnum is not null and it should fire the way they want.

     

     

    Jason Luke

    Analyst-Application Dev Lead

    Kinder Morgan, Inc.

     






  • 14.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Thu June 09, 2022 08:50 AM
    Here's the thing, the PMNUM field can only be populated through the WOGEN process.  Whereas the WORKTYPE field can be populated through multiple methods.

    The PM work order can be generated as a result of someone using the Generate Work Order menu option in the PM application or using the PMWoGenCronTask cron task or using the Generate Work Order menu option in the Condition Monitoring application or using the MeasurePointWoGenCronTask cron task.

    Why do I say this?

    Typically, a PM has the work type = PM, but yet I can create a work order from an SR and then assign a work type=PM to that work order.

    So, when's a PM work order not a PM work order?  Overall it doesn't matter, it's a work order.

    Back to the OP, I'm trying to understand the need to know if it was created manually vs cron task.  In order to generate manually, the user must have those rights granted to them.  That means someone made the decision that a security group has been that option granted, and thus anyone who's in that group has received the appropriate training (duh, of course).  If generated manually, the WORKORDER.REPORTEDBY field will have that user's name, whereas if generated via a cron task that the same field will have the name from the CRONTASKINSTANCE.RUNASUSERID instead, which is typically not an ordinary user as indicated by Wayde.

    I hope that gives you an answer.

    ------------------------------
    ===============================
    Craig Kokay,
    Lead Senior Maximo/IoT Consultant
    ISW
    Sydney, NSW, Australia
    Ph: 0411-682-040
    =================================
    #IBMChampion2022
    ------------------------------



  • 15.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Thu June 09, 2022 08:04 PM
    Another option based on cron vs user would be to test the interactive implicit variable in the automation script.

    from the IBM Docco 
    interactive Boolean All launch points Indicates whether the script is running in an active user session or a non-user background session, such as integration transaction processing.
    eg
    if interactive == False:
      #do your cron thing here 
    else:
      #its interactive

    I'm not sure if I understand your comment "We cannot write on WO save".  I assume this means you want to apply your logic before the save event?  It would be interesting and useful to hear what logic needs to be applied as this would be helpful in suggesting options.  Based on what I interpret this should allow you to to achieve what you want with autoscripts

    ------------------------------
    Michael Kasteel
    Director
    ISW
    0402830412
    ------------------------------



  • 16.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Fri June 10, 2022 02:35 AM
    Hi,

    interactive does not always work correct. IBM Support told me (years ago) to check if the user has a webclientsession is more reliable.

    if service.webclientsession():
      # its interactive
    else:
      # its not interactive, so cron​​

    ------------------------------
    Andreas Brieke
    IT Service Management Consultant
    SVA System Vertrieb Alexander GmbH
    ------------------------------



  • 17.  RE: Determine if WO was created from a scheduled PM -or- manual PM action?

    Posted Thu June 09, 2022 09:15 PM

    Generally speaking, the quick way to tell is check who's in the REPORTED BY field.

     

    Automatic WOGEN PM work orders are usually created by a system user such as MAXADMIN.  PM work orders generated via the PM screen by a user will have the user's info. In the Reported By.

     

    This assumes, of course, that you have the MAXADMIN user ID locked down.