Maximo

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.


  • 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 User1971 Sun May 09, 2021 03:00 PM
    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 User1971 27 days ago
    @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.



  • 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 User1971 Fri May 14, 2021 12:45 PM

    @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.
    (We're not using the PLUSSGEOJSON field/functionality in our Maximo implementation.)"

    [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.

     



  • 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 User1971 28 days ago


  • 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.

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