hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Hello

It's possible you are missing authentication headers when calling OSLC methods that require elevated permissions.
A valid JSESSIONID is not enough when calling wsmethod: changeStatus

Regards

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Hello

It's possible you are missing authentication headers when calling OSLC methods that require elevated permissions.
A valid JSESSIONID is not enough when calling wsmethod: changeStatus

Regards

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Hi,

HTTP 401 clearly means that there is some issue with authentication. 
There may be many reasons for it, depending on your security settings.

1. Do you see anything in your application server logs?
2. Do you use application server security or MX native auth.?
3. How does your WEB-INF.xml file look like for maximouiweb and maxrestweb modules? 
4. I must say using UI-session for REST calls sounds unusual. Have you been considering switching to APIKEYs?
   
   

Hello

It's possible you are missing authentication headers when calling OSLC methods that require elevated permissions.
A valid JSESSIONID is not enough when calling wsmethod: changeStatus

Regards

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

If you have access to the server logs, I would look to see the stack trace. It's possible that there's logic somewhere getting a system user account and there's an issue with that system user account. I'm not exactly sure you would see it in the one path and not another but it could help point you in the correct direction. 

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Maximo often provides multiple ways to do something, and I typically like to avoid "this is the correct way" because there's often reasons the other methods exist. However, I'm extremely passionate about this that above is the correct way to make status changes. 

The webmethod exists primarily because the MIF framework didn't support backdating status changes. For example, on Maximo Mobile the time it synchronizes to the server may not be when the transaction occurred on the device. The webmethod allows you to provide the status date. 

In 9.0 of MAS (which I realize you're not on), IBM added the ability to backdate with a new non-persistent attribute STATUSIFACEDATE to most of the common objects (and this can be added to any statusable object). This eliminates the one scenario the webmethod provided additional functionality 

Why do I prefer the non webmethod approach?

1) There have been a series of issues with webmethod status changes because it is its own custom code flow. It still executes the underlying status change logic but is a unique code path with its own logic. For example, Known Issue: DT417452 was only an issue in the role-based applications that used the webmethod. If you changed the status to INPRG in desktop Maximo (which used the normal flow, similar to the traditional MIF import), it would have worked. Inspections and other apps have had similar issues, sometimes only when you have certain industry solutions installed.
2) You are unable to intercept and process webmethod calls with the traditional automation script functionality like an OSIN automation script. A good example of where this is useful is two users try to start a work order in a mobile application. Maximo will throw an error that the work order is already in progress and block all subsequent transactions until the user deletes the error. If you used the simpler import, you could add your own logic to skip the message if the work order was already in an INPRG status and avoid user frustration. 
3) In the Maximo Mobile applications, you need to build a special payload for what to send to the server & how to update the local data to match what you expect the final outcome to be. When you invoke a webmethod to put the WO to APPR for example, you need to build a special local payload to say the status field will be APPR after it synchronizes to the server. Whereas if you use the simpler approach, you're setting the status field already and saving the data source like normal. It sends to the server correctly and displays correctly on the mobile device without needing to write the special logic.

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

Thank you so much, Steven. I wasn't aware of those differences; this is very helpful.
So, just to be sure, if I see "wsmethod" in the queries, does that generally refer to the web method?

Thanks again.

Maximo often provides multiple ways to do something, and I typically like to avoid "this is the correct way" because there's often reasons the other methods exist. However, I'm extremely passionate about this that above is the correct way to make status changes. 

The webmethod exists primarily because the MIF framework didn't support backdating status changes. For example, on Maximo Mobile the time it synchronizes to the server may not be when the transaction occurred on the device. The webmethod allows you to provide the status date. 

In 9.0 of MAS (which I realize you're not on), IBM added the ability to backdate with a new non-persistent attribute STATUSIFACEDATE to most of the common objects (and this can be added to any statusable object). This eliminates the one scenario the webmethod provided additional functionality 

Why do I prefer the non webmethod approach?

1) There have been a series of issues with webmethod status changes because it is its own custom code flow. It still executes the underlying status change logic but is a unique code path with its own logic. For example, Known Issue: DT417452 was only an issue in the role-based applications that used the webmethod. If you changed the status to INPRG in desktop Maximo (which used the normal flow, similar to the traditional MIF import), it would have worked. Inspections and other apps have had similar issues, sometimes only when you have certain industry solutions installed.
2) You are unable to intercept and process webmethod calls with the traditional automation script functionality like an OSIN automation script. A good example of where this is useful is two users try to start a work order in a mobile application. Maximo will throw an error that the work order is already in progress and block all subsequent transactions until the user deletes the error. If you used the simpler import, you could add your own logic to skip the message if the work order was already in an INPRG status and avoid user frustration. 
3) In the Maximo Mobile applications, you need to build a special payload for what to send to the server & how to update the local data to match what you expect the final outcome to be. When you invoke a webmethod to put the WO to APPR for example, you need to build a special local payload to say the status field will be APPR after it synchronizes to the server. Whereas if you use the simpler approach, you're setting the status field already and saving the data source like normal. It sends to the server correctly and displays correctly on the mobile device without needing to write the special logic.

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.

wsmethod is a specific type of action declared in java code but there are ways to develop action automation scripts, java classes, etc. that wouldn't show as wsmethod. But regardless, for changing status, the goal is to avoid invoking an action (in my opinion). 

There are other things that are webmethod like starting a labor timer that require being an action (since it requires invoking a specific method in the WO class). So for clarity, I'm not saying you should never use a webmethod. 

Thank you so much, Steven. I wasn't aware of those differences; this is very helpful.
So, just to be sure, if I see "wsmethod" in the queries, does that generally refer to the web method?

Thanks again.

Maximo often provides multiple ways to do something, and I typically like to avoid "this is the correct way" because there's often reasons the other methods exist. However, I'm extremely passionate about this that above is the correct way to make status changes. 

The webmethod exists primarily because the MIF framework didn't support backdating status changes. For example, on Maximo Mobile the time it synchronizes to the server may not be when the transaction occurred on the device. The webmethod allows you to provide the status date. 

In 9.0 of MAS (which I realize you're not on), IBM added the ability to backdate with a new non-persistent attribute STATUSIFACEDATE to most of the common objects (and this can be added to any statusable object). This eliminates the one scenario the webmethod provided additional functionality 

Why do I prefer the non webmethod approach?

1) There have been a series of issues with webmethod status changes because it is its own custom code flow. It still executes the underlying status change logic but is a unique code path with its own logic. For example, Known Issue: DT417452 was only an issue in the role-based applications that used the webmethod. If you changed the status to INPRG in desktop Maximo (which used the normal flow, similar to the traditional MIF import), it would have worked. Inspections and other apps have had similar issues, sometimes only when you have certain industry solutions installed.
2) You are unable to intercept and process webmethod calls with the traditional automation script functionality like an OSIN automation script. A good example of where this is useful is two users try to start a work order in a mobile application. Maximo will throw an error that the work order is already in progress and block all subsequent transactions until the user deletes the error. If you used the simpler import, you could add your own logic to skip the message if the work order was already in an INPRG status and avoid user frustration. 
3) In the Maximo Mobile applications, you need to build a special payload for what to send to the server & how to update the local data to match what you expect the final outcome to be. When you invoke a webmethod to put the WO to APPR for example, you need to build a special local payload to say the status field will be APPR after it synchronizes to the server. Whereas if you use the simpler approach, you're setting the status field already and saving the data source like normal. It sends to the server correctly and displays correctly on the mobile device without needing to write the special logic.

Here is how I do it in MAS 9.0.

First use rest to get the right URI of the work order:
https://URL.com/maximo/api/os/MXWO?oslc.where=wonum=187356

Parse the href response and get the URI. Use that to send a post through with the status change.
POST: https://URL.com/maximo/api/os/MXAPIWODETAIL/_U1UvMjAxMTY0Mw--?lean=1

x-method-override: Patch

patchtype: MERGE

content-type: application/json

body:

There is probably an easier way but that is what I could get to work for me. 

hello there

I have an interesting problem in IBM Maximo Asset Management 7.6.1.3 when changing the status of a work order via API.

I'm using the following method:
`curl --location '{{url}}/maximo/oslc/os/MXWODETAIL/{{woid}}?lean=1&action=wsmethod:changeStatus`
`--header 'x-method-override: PATCH'`
`--header 'patchtype: MERGE'`
`--header 'properties: actstart,actfinish,status,statusdate,changedate'`
`--data '{"status": "INPRG"}'`

and I get the following error:

    `"reasonCode": "BMXAA7901E",

    `"message": "BMXAA7901E - You cannot log in at this time. Contact the system administrator".`

    `"statusCode": "401"

The strange thing is that I'm logged in and have a valid JSESSIONID cookie, and I can perform other read and change actions (GET and POST), but when I try to change the status, the error appears.

Does anyone have any idea what the problem might be?

Thank you very much.