We have some documentation on our JSON API here: https://community.ibm.com/community/user/asset-facilities/viewdocument/maximos-rest-api-aka-json-api-os?CommunityKey=ed77c224-45e2-47b0-b574-cc31496f9a41&tab=librarydocuments

The Maximo REST API Guide on that page is particularly useful. 

Most customers integrating with Maximo today via webservices are utilizing the object structure directly (not configuring enterprise services). Some systems are fire and forget and require writing to the JMS in Maximo to handle when errors occur. In an ideal scenario, the sending system is intelligent enough to track these failures and handle reprocessing because there will be scenarios where Maximo is unavailable so you shouldn't depend on Maximo to always be able to manage the queue. If the sending system is fire and forget and can't queue these messages, you'll lose messages anytime Maximo is unavailable. To handle Maximo being available but the message failing (bad data), you can have the webservice write to JMS which will require an enterprise service. To the best of my knowledge, you can only do this with a SOAP web service (not our REST API) but we're adding stuff all the time to our REST API so it's possible I've missed it.

JSON Mapping is useful when you can't make the sending system send the message in a way that Maximo can consume. For example, we use this with our ESRI integrations to transform from ESRI JSON body into the format Maximo expects. There is an option to specify the endpoint, but most customers specify the object structure. You should be creating a distinct object structure for most integrations so that you can make changes to it as needed without impacting other integrations. 

Are you looking for a bidirectional integration (IE system A sends to Maximo and Maximo sends back to system A)? If so, you will need to configure an endpoint back to the other system (typically using the HTTP handler) and most likely publish channels in Maximo to send the data from Maximo back to the original system. And again, assuming the other system can't process the Maximo message you can use JSON mapping to transform the message from the Maximo format to the format the other system needs. As part of the configuration, you define whether it's inbound or outbound to Maximo. 

Hi, I've just found this thread. I'm working on an integration design for contractor work reporting, but generically, my question revolves around how to make the comparative decision between soap / rest and xml / json, for example soap with xml or soap with json what does that require, rest with xml / json, with regard to what maximo configuration tasks may be required and what maximo capabilities may / not be available for a given combination.

It's bidirectional with a sample flow somewhat like, in my custom client create a new worksheet record and save to Maximo. As part of that creation, query for "my work" against an endpoint containing woactivity and related planned work attribution, find some line I've worked on, enter some qty of units worked, save to Maximo, requery to see current state of my worksheet. Ultimately send some indicator of "complete" to Maximo to initiate any reconciliation step then initiate approval and invoice generation processes. 

So, if we start with creation of an object structure and let's say the client prefers json, then, if we do soap with json, then ? if we go to rest with json then? 

I'm working in a 7.6.1.3 environment with T&D added.  

I'm happy to read any materials someone may point me to, to ask a more informed question here, if that's required. Thx. 

We have some documentation on our JSON API here: https://community.ibm.com/community/user/asset-facilities/viewdocument/maximos-rest-api-aka-json-api-os?CommunityKey=ed77c224-45e2-47b0-b574-cc31496f9a41&tab=librarydocuments

The Maximo REST API Guide on that page is particularly useful. 

Most customers integrating with Maximo today via webservices are utilizing the object structure directly (not configuring enterprise services). Some systems are fire and forget and require writing to the JMS in Maximo to handle when errors occur. In an ideal scenario, the sending system is intelligent enough to track these failures and handle reprocessing because there will be scenarios where Maximo is unavailable so you shouldn't depend on Maximo to always be able to manage the queue. If the sending system is fire and forget and can't queue these messages, you'll lose messages anytime Maximo is unavailable. To handle Maximo being available but the message failing (bad data), you can have the webservice write to JMS which will require an enterprise service. To the best of my knowledge, you can only do this with a SOAP web service (not our REST API) but we're adding stuff all the time to our REST API so it's possible I've missed it.

JSON Mapping is useful when you can't make the sending system send the message in a way that Maximo can consume. For example, we use this with our ESRI integrations to transform from ESRI JSON body into the format Maximo expects. There is an option to specify the endpoint, but most customers specify the object structure. You should be creating a distinct object structure for most integrations so that you can make changes to it as needed without impacting other integrations. 

Are you looking for a bidirectional integration (IE system A sends to Maximo and Maximo sends back to system A)? If so, you will need to configure an endpoint back to the other system (typically using the HTTP handler) and most likely publish channels in Maximo to send the data from Maximo back to the original system. And again, assuming the other system can't process the Maximo message you can use JSON mapping to transform the message from the Maximo format to the format the other system needs. As part of the configuration, you define whether it's inbound or outbound to Maximo. 

Inventory usage in Maximo can be very complicated with staging, shipments, splitting transactions across bins, etc. If this is your first Maximo integration, I would recommend getting help. 

Speaking at a very high level, you typically use publish channels and end points to send data from Maximo to another system. There will be some decisions that have to occur about how you plan to transform the Maximo message into the format you need. But before you get into that you really should step back.

Step 1 is to figure out the business logic of the integration and any rule differences between Maximo and this other system.

Business logic will be concepts like what types of data (IE what fields, objects, etc.) do we need for this other system? Do we need integrations for other data (sites, storerooms, GL accounts, items, etc.) that would be involved in this integration? When should the message be sent from Maximo to the other system? Is it immediately or once it reaches a certain status? 

Regarding rule differences, building an integration requires a deep understanding of both products because there are often fundamental differences in the two products that impact your design. For example, Maximo does PO revisioning at a header level and JDE does it at a line level. When a change occurs in JDE, a new line is (or at least may be) created. You need to understand these differences to design the integration properly.

Step 2 is to identify the URL, body, headers, etc. required to send the transaction to the other system and get it working in a tool like Postman. If you can't make it work in a tool like Postman there's no point in spending any time trying to make Maximo send to that system.

Step 3 is determine how you're going to transform the message from Maximo to the other system and work on getting that implemented.

Step 4 is to figure out what changes from the other system you need to send back to Maximo and again how you're going to transform it