Maximo- Update work order using RESTApi by passing wonum and siteid instead of workorderid - maximo

We are currently on Maximo 7.6.1 and have started to use Restful APIs and was wondering if there is a way to update a work order using RESTApi by passing wonum and siteid instead of workorderid.
We would like to avoid one additional GET call for our middleware to retrieve the workorderid and then use it in the PUT request.
Using this URL (OS as well) tries to insert a record even though the HTTP method is PUT.
/maxrest/rest/mbo/WORKORDER?_action=AddChange&siteid=XXX&wonum=7065644&description=Testing
Any pointers will be helpful.
Thanks

The IBM documentation appears to suggest you can only update existing records with the unique ID:
Use the PUT method to update or insert a resource. An update request
must provide the unique ID of the resource. To update an object
structure resource, the ID of the main object is required.
https://www.ibm.com/support/knowledgecenter/en/SSLKT6_7.6.0/com.ibm.mif.doc/gp_intfrmwk/rest_api/r_rest_put_method.html
The response received using the url you provided appears to bear this out in as far as it indicates the work order cannot be created as it already exists:
Error 400: BMXAA4129E - The record for Site=BEDFORD, Work Order=1234
already exists. Ensure that the key value for the given record is
unique.
Reviewing the information at the following url I wasn't able to determine a method to perform the update without the unique ID:
https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/02db2a84-fc66-4667-b760-54e495526ec1/page/87348f89-b8b4-4c4a-94bd-ecbe1e4e8857/attachment/0a884bde-d17e-471b-b046-7f8feddfd267/media/MaximoNextGenRESTAPI%20%281%29.pdf
In addition the Maximo RESTful API Swagger documentation indicates a POST to /os/mxwo is used to "Create a new resource":
/maximo/oas3/api.html?includeactions=1#/Work_Order_Definition_(MXWO)/post_os_mxwo
Whilst a POST to /os/mxwo/{id} is used to "Update WORKORDER Object":
/maximo/oas3/api.html?includeactions=1#/Work_Order_Definition_(MXWO)/post_os_mxwo__id_
I was however able to update an existing work order using the unique ID. This being the case I can only suggest one of the following:
If you're creating the work order first using the REST/OSLC API,
retrieve and store the unique ID from the response received when the
record is created.
If (1) above is not possible, perform a GET and use parameters in
the query to filter on wonum and siteid and only receive back the minimum of
fields (e.g. workorderid only).
If neither (1) or (2) are feasible investigate whether it's possible
to customise Maximo and create your own endpoint for the work order
object structure that takes wonum and siteid as parameters,
retrieves the mbo and performs the update.

Related

Docusign Rest API - Update User using PUT method - can we change userStatus

I am exploring update user and I want to update users status using PUT method but userStatus is not getting updated?
Is that not allowed?
If you're able to provide a code example (Using fake data) of the API call you are attempting we can get a better look at what might be causing this PUT call to not work.
These are the following options a user can have for their userStatus:
ActivationRequired
ActivationSent
Active
Closed
Disabled
These values are unable to be changed via the API. Is there a specific user case you need for this to be achieved via the API?
You can, however, close a user membership via a DELETE call to the following URL:
/restapi/v2.1/accounts/{accountId}/users

For Azure DocumentDB input binding, Is there a way to get the document id from the headers?

I am trying to use Azure function to automate a process, where by a third party send me a http request with document id in the http header. I want to use that id to use documentdb input binding.
I have already learnt that we can do it from the body. Thanks to Brett Samblanet for replying on the Azure documentation itself.
Alternatively I can redirect it further by putting "document id" into the query string, that will be bit inefficient but still better than not being able to use it at all. So it will be great If anybody can please help me to find out a way to:
use http header as document id.
use query string as document id.
At the moment you can only bind to values from the request body. We have a PR already merged that expands this to allow binding to the query string as well. But this change is not currently in production (I can update this response when it is): https://github.com/Azure/azure-webjobs-sdk-script/pull/568
There is currently no support for headers but I've filed an issue: https://github.com/Azure/azure-webjobs-sdk-script/issues/591
FYI -- I also copied this answer here: https://azure.microsoft.com/en-us/documentation/articles/functions-bindings-documentdb/

Efficient way to read+write data from CouchDB

I am implementing an application that includes a user who logs in to access a document stored in a hosted CouchDB store. The user provides their credentials to the app, and once the app authenticates them, the app then has two jobs:
Get the Document ID associated with that user's data
Update the "lastOpened" value stored in that document
I am having to do those two things in a way that seems rather inefficient: I read a View which maps the app's user identifier (their email address in this case) to their Document ID. Once I have the Document ID (and have added it to the session for later use) I then have to request the Document, uptick the "lastOpened" value, then save the Document back to the store.
That looks like 3 trips to the database to me: 1. Get the Document ID from the View, 2. Get the Document, using that ID, 3. Save the updated Document.
Is there anyway to reduce that work to fewer database trips?
If you can change the document structure, you could use the user's login name as the document ID. That way, you don't have to use a view. Using update handlers, you could even do all the work in one request.
That looks like 3 trips to the database to me: 1. Get the Document ID from the View, 2. Get the Document, using that ID, 3. Save the updated Document.
Is there anyway to reduce that work to fewer database trips?
You can fetch document from a view by adding "?include_docs=true" query parameter in request. So two steps instead of three.

DocuSign embedded signing returnUrl length limit?

While working on a DocuSign embedded signing process (which has worked in the past), I noticed that after signing the document the 'event' parameter was missing from the 'returnUrl' I was being sent back to.
The returnUrl looks like:
http://www.example.com/index.php?param1=value1 ... &param10=value10
The parameters were being passed on returning from signing, but no event=signing_complete parameter was being added. I tried removing the parameters, and suddenly the event parameter returned.
After further experimentation, I discovered that the returnUrl parameter has a 500 character limit. Anything more is truncated. This will also truncate the event parameter from the end of the returnUrl.
This does not seem to documented in the DocuSign REST API documentation (https://www.docusign.com/p/RESTAPIGuide/Content/REST%20API%20References/Post%20Recipient%20View.htm).
So, is this a feature or a bug? Other than using session or database storage, is there a recommended workaround for the 500-character limit?
There might be some limits to the URL that is being passed in by the web servers themselves. I have not seen a lot of people hit this limit because probably most of the time folks do not put that much information into a return URL.
If you are coming from software that has session state you can use the following technique:
1) add the information you were previously sending via URL to a dictionary or a collection object and save it in the session on the server. Follow the best security practices for that one so that this information can't be easily accessed (there is a ton of material on how to do this properly and it's probably beyond this answer)
2) in the url instead of all the keys and values just provide the key to your collection.
3) upon return from DocuSign look up the object and retrieve the passed in information.
If there is no state in your software you can try using other properties of the envelope to put the additional information such as envelope custom fields. You can populate those on create and you can retrieve the information back when the control comes back to your software. Here is the article about custom fields: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Get Envelope Custom Field Information.htm

Retrieve a mailchimp list via GET

I am trying to retrieve a MailChimp list.
I have an API Key and a List ID, and while I understand that I can use the MailChimp API wrapper to achieve this I prefer to avoid implementing it since I only need to do this one task.
When I enter in my browser:
https://us3.api.mailchimp.com/2.0/lists/members?apikey=*****&id=******
I get a JSON result of my list - but it is limited to the first 25 subscribers. I don't see anything in the MailChimp API documentation about submitting a GET request to retrieve a list. Is it possible to do so? If so, how can I retrieve a full list?
Read this: http://apidocs.mailchimp.com/api/2.0/lists/members.php
Options are available via pagination.
You are supposed to POST the values in your request.
Looks like the best method is to use the MailChimp list method which "Exports/dumps members of a list and all of their associated details. This is a very similar to exporting via the web interface."
Read more at http://apidocs.mailchimp.com/export/1.0/list.func.php
Another option is to use API v1.3 listMembers function, more info here: http://apidocs.mailchimp.com/api/1.3/listmembers.func.php. v1.3 is deprecated, but it still functions properly.

Resources