MxLoader

Hello everyone,

Recently my company switched to MAS8 and we have changed our standard interactions from Service: OS to Service: REST with API key. Previously used files to create assets, route, and workorders are working but no longer return Object IDs. It is mentioned in the user guide that object ID are not supported on rest return but the change log has the following entry on 8.4.1 (Object IDs can be returned specifying them in square brakets '[]'). I noticed that previous version of Mxloader, the [] was blocked with an error message on the rest calls whereas the new version allow it. The object id (in this case, route) is returned in the Trace logging file but doesn't appear in Excel after processing (but the result does). 

2025-01-07 14:51:44 [DEBUG] Parsing JSON: 
2025-01-07 14:51:44 [TRACE]   _responsedata
2025-01-07 14:51:44 [TRACE]     route
2025-01-07 14:51:44 [TRACE]   _responsemeta
2025-01-07 14:51:44 [TRACE]     status
2025-01-07 14:51:44 [TRACE]     Location
2025-01-07 14:51:44 [TRACE]     Content-Type
2025-01-07 14:51:44 [DEBUG] Parsing JSON: 
2025-01-07 14:51:44 [TRACE]   _responsedata
2025-01-07 14:51:44 [TRACE]     route
2025-01-07 14:51:44 [TRACE]   _responsemeta
2025-01-07 14:51:44 [TRACE]     status
2025-01-07 14:51:44 [TRACE]     Location
2025-01-07 14:51:44 [TRACE]     Content-Type
2025-01-07 14:51:44 [TRACE] Parsed response

  {
,

    {
      "ROUTE": "THEKEYOFTHEROUTE"
    },

    {
      "STATUS": "201"
    }
  }
]

So I am trying to figure out if it is a bug based on the new changelogs or is still not yet supported? 

Or if it is working for others? 

And if it isn't going to be supported in the near future if there is opportunities for creating a fork? Rather than just writing a separate in-house REST handler.

Hi James,

It's hard to me to answer if it's included in release plan for MxLoader future versions to fix this or add this as a feature - probably it's a question to Bruno directly :)

What I can answer is a short description of workaround I've applied when I needed to load a massive amount of work orders to Maximo and later to apply some operations like status changes, etc - where I needed reference to created WONUMs. 
Maybe workaround is obvious - let's see :)

It's all about finding a field in Maximo, which you can temporarily fill with some data.
For this purpose I've used ENVIRONMENT field which was empty in my case, but obviously any other field can be used (even added by quick DDL script like "ALTER TABLE ADD CUSTOMCOLUMN...").

Later, in my first loading with MxLoader I've - beside of real WO data - loaded sequence 1,2,3,... to this column.

When it has been loaded, on next MxLoader tab, I've queried Maximo for WO data with Query defined as ENVIRONMENT="*" which gave me the list of all WOs I've loaded moment ago, with whatever attributes I wanted (including WONUMs of course!).

That data can be later used to load whatever we want!

In the end, simple script to clean after our loading can be executed - and that's all!

UPDATE WORKORDER SET ENVIRONMENT = NULL
WHERE ENVIRONMENT IS NOT NULL

As said - maybe that's something obvious, but at least it let us to walk around problem with not returned ObjectIDs!
Hope it will help somehow!

Regards!

------------------------------
Piotr Ozaist
Afry
------------------------------

Thank you for confirming Piotr, it is greatly appreciated. I like the idea of staying within the tool and using additional unused fields if available for a two-step approach rather than building or teaching a new process.

For anyone who is interested, here is a link to my article, containing further details about the workaround I described.

A workaround to allow MxLoader to return Object IDs using square brackets '[]' in MAS

------------------------------
Yuri Vedovato
Tempestive
------------------------------

Thank you Yuri for troubleshooting the root cause of the issue.

I have released MxLoader 8.4.3 that solves this issue.

Let me know if it's ok now.

------------------------------
Regards
Bruno Portaluri (MaximoDev)
------------------------------

I have thoroughly tested the new version over the past few weeks, and it appears that the issue has been fixed.

Thank you, Bruno, for the prompt fix.