Developing its own M3 API in a Multi-tenant Cloud environment : what are the options ?

Hello,

I am not a developer. So, sorry if my question may seem trivial.

But I would like to have a better idea of the solutions available to us about the following topic: developing its own M3 API in a Multi-tenant Cloud environment.
I know that there is the possibility to use the CMS100MI functionality.

But if the API we want to develop is to pool in a code that calls several standard (or not) M3 APIs, this method does not seem to me suitable.

I don't know if I have been clear enough?

I think there are several methods more or less complex in the sense of M3 extensibility.
But I'm having trouble getting a clear picture of the situation.
Thank you for your lights

Find more posts tagged with

Accepted answers

Legacy Contributor

That is another functionality in XtendM3 tool. You are correct, that XtendM3 initially was born with the idea of being triggered by extension points.

But a lot of new functionality has been added and already used and live at several customers.

You can build API's in XtendM3 and these API's will act like standard M3 API's. Meta data can be seen in MRS001 and you can call them through ION in workflows etc.

You can also create custom database tables. These tables will also act like normal M3 standard tables and are available in Event Hub /Event Analytics.

Finally you can also build Batch programs in XtendM3 to facilitate longer running custom jobs.

benjamin-nowak

Good overview Jan.

Yes, these would be developed via XM3. Be careful in the design though as where we can execute existing API's, this tool cannot call existing functions within core M3. So in your initial example to have a driver application to execute a series of other API's it would be entirely appropriate.

But if that is all you are doing, I would also consider creating an IEC script and custom BOD for the processing.

A workflow/data flow to be triggered is another possibility as these can also execute standard API's and include basic logic branches.

It all comes down to communications and how you want to launch it.

All comments

Legacy Contributor

Not knowing the case in more detail makes the answer a bit uncertain, but I think you should have a look at XtendM3.

In XtendM3 we can custom build API's and we have full access to the M3 database.

Denis MARETTE

Yes I understand Jan your caution.

But I deliberately asked the question in a generic way to be able to measure the range of possibilities.

For me, developing in XtendM3 is associated with asking Infor to want to run custom code at certain predefined exit points of the standard M3 logic so as not to touch the core of the programs unlike an on-premise environment.

When you talk about using XtendM3 to develop an API, is that related to this or is it another facet of XtendM3 that I don't know about yet?

Thank

Legacy Contributor

That is another functionality in XtendM3 tool. You are correct, that XtendM3 initially was born with the idea of being triggered by extension points.

But a lot of new functionality has been added and already used and live at several customers.

You can build API's in XtendM3 and these API's will act like standard M3 API's. Meta data can be seen in MRS001 and you can call them through ION in workflows etc.

You can also create custom database tables. These tables will also act like normal M3 standard tables and are available in Event Hub /Event Analytics.

Finally you can also build Batch programs in XtendM3 to facilitate longer running custom jobs.

benjamin-nowak

Good overview Jan.

But if that is all you are doing, I would also consider creating an IEC script and custom BOD for the processing.

A workflow/data flow to be triggered is another possibility as these can also execute standard API's and include basic logic branches.

It all comes down to communications and how you want to launch it.

antonio-caria

xTendM3

Copyright © 2025 Infor. All rights reserved.