How to integrate your application with Maximo?

How to integrate your application with Maximo?

Allegro Systems ( has implemented a connector to Maximo that allows HTTP calls with XML parameters. This connector, called ASIConnect, enables a quick interface to Maximo. Attached is the specification document of the connector (Spanish version).

With this connector, Maximo is able to call your OutSystems application:
- Using as URL your OutSystems’ entry point
- Sending its data through a HTTP parameter called XMLData
Then, you are able to act upon the Maximo call, reading the XML data (see the Outsystems solution Extension XML to quick load the XML data).
The reply to the call from Maximo will be done by a XML.

With this connector, you are also able to call Maximo from your OutSystems application:
- Using as URL a pre-established one with Maximo team
- Sending your data through a HTTP POST call, with a parameter called contenido. You will need the HTTP extension to do this call.

Attached you’ll find a sample OML with the necessary extensions:
- The CreateNewRequisition web screen shows an example for receiving data from Maximo. Note that this sample does not use the Extension XML solution, but I would recommend you to use it (I haven’t done it because this sample was created before the creation of the Extension XML solution).
- The MAXIMO_PostRequest action shows an example for sending data from Maximo.
- The sample assumes that you have previously installed the following OutSystems solution: Extension HTTPRequestHandler

As soon as possible, I will convert this post into a solution on the Solution’s site.

For more information about Maximo, please follow the MRO site at

Good integrations!
Olivier Carneiro
A character encoding problem might arrive when Maximo calls your OutSystems application.
This is because Maximo character encoding is defined at installation-time. And Allegro's recommendation (I don't know if it is MRO recommendation, too), is to use the more language-specific charset. At Portugal, Maximo is installed in ISO-8859-1.
Since OutSystems Hub Edition is installed in UTF-8 mode, when Maximo calls your OutSystems application via an HTTP post, all Portuguese characters in HTTP parameters are lost.
The solution (thanks to Paulo Garrudo) was to change the Web.config of the OutSystems espace, replacing:
<globalization requestEncoding="utf-8" responseEncoding="utf-8" /> by
<globalization requestEncoding="ISO8859-1" responseEncoding="utf-8" />

This new Web.Config file was attached to an extension used by the OutSystems espace, overwriting the OHE default Web.Config, each time the eSpace is published.

Attention: this is a work-around and it might not be compatible with further versions of OutSystems Hub Edition. You will need to cross-check this change after each upgrade of the Hub Server.

Thanks for posting all the information, extensions and samples!

But now I have another problem, we're still using version 3.1.3 of the HubServer platform, and all the extensions are for version 3.2, so I can't use them... Are there versions of them for 3.1.3?

It's not a major problem if there aren't, now that I know what to do, but it would be handy to have them.

Hi Carlos,

The OMLs/XIFs attached to the post are for version 3.1.3. I assume you are referring the extensions from the solutions.

Attached is the 3.1.3 version of the HTTPRequestHandler.
For the Extension XML solution, follow the «Version History» link. The first published version is for 3.1.3. Note that the sample I provided does not use this extension, so it is not a «must have». It is an accelerator.



Well, following your (OutSystems) recommendation we'll upgrade to 3.2, so it seems we'll no longer need the older versions.


We tried that but it didn't work.

The web.config says that the requestEncoding is ISO-8859-1 but it still goes as UTF-8.

I've even tried changing the extension to force the conversion to ISO-8859-1 but nothing happens.

Any ideas?

Hi Carlos,

Have you been able to confirm that Maximo is sending the data in the expected encoding?
I would advise you to install a http sniffer and check the data that Maximo is actually sending.

Anyway, attached you can find another solution (that is actually working in an integration with Maximo): an OML that acts like a proxy. The ideia is:
Maximo sends http request to the MaximoTranslator eSpace (EntryCreateNewRequisition entrypoint) and the eSpace forwards it to your application.
This eSpace has the web.config in ISO encoding for request and UTF-8 for responses.

Remove the web.config changes from your eSpace, configure the MaximoTranslator eSpace to call your eSpace. Finally, change the URL that Maximo is using: Maximo shall call the MaximoTranslator eSpace, instead of your application.

I hope this can help you to solve your problem
Ah, sorry...

We receive the data from MAXIMO correctly, it's when we send data do MAXIMO that the problem happens.

What it seems is that the .NET Framework always sends the request in UTF-8, even when we specify in the web.config that it should use ISO-8859-1.

What I was wondering is if is there a way to force the request to be encoded as ISO-8859-1 regardless of what the web.config says...

Hi Carlos,

Assuming you are returning data in the same request, you should change the response enconding in the web.config from:
<globalization requestEncoding="ISO8859-1" responseEncoding="utf-8" />
<globalization requestEncoding="ISO8859-1" responseEncoding="ISO8859-1" />

Let me know if it works.

I tried that but the people from MAXIMO are saying that they still don't receive the characters correctly. But I tested it in IE 6, IE 7 RC1 and Firefox and the encoding *is* ISO-8859-1.

Additionally, there's a problem with that solution, since the .aspx files have this tag: <META http-equiv="Content-Type" content="text/html; charset=utf-8"> that specifies a different encoding from the actual one, all "special" characters show up strange in the browser (in all of them as above). Is there a way to solve this other than replacing all text in the HTML with expressions?

Hi Carlos,

Please try to invoke the SetResponseEncoding("ISO8859-1") in the screen preparation of your screen using the attached extension. It should work....
Hi Carlos,

The previous extension was missing the content-type header. Please test this one instead.