Infor M3 CE Enterprise collaborator apis

Hello,

We have created an enhancement request to ask infor to create apis in order to interact with Enterprise collaborator Adminsistration.

The description of this enhancement :

In order to be able to monitor from an external tool, integrations made with M3 Enterprise Collaborator. We would need apis that would allow us to interact with Enterpise Collaborator Administration.

We would need

An api allowing us to list communication channels like Enterprise Collaborator Administration/Communications/Channel Control

An api that would allow us to view messages with different search filters: Like Enterprise Collaborator Administration /Messages/Advanced Search with the possibilities to filter by date, agreement, manifest informations…

An api that would allow us to redetect/retry/delete/verify messages by Enterprise collaborator message uuid

An api for getting message logs by Enterprise collaborator message uuid

if you think this functionnalites will be useful, don't hesitate to vote.

Regards Fred

Find more posts tagged with

Accepted answers

All comments

Legacy Contributor

What's the ER number?

There's no new ER's for Product "M3 Core Technology - Enterprise Collaborator" in Concierge.

fredericlebars

Hello,

ER 109855

Fred

Nichlas Karlsson

Hi,

These are technical requests. We need business cases, what do you want to do. Then we decide whether to add this to our roadmap, and also what technical solution it will be.

It is on our roadmap to adopt all MEC UIs to Portal, which means rewriting the Administration UI. Administration tasks such as pausing/resuming communication channels, finding messages, redetecting/retrying/verifying messages, view message logs etc. should be done in the Enterprise Collaborator Administration UI, not from an external UI or tool. MEC will also adopt to Health Service, so that you for example can get notifications and emails for failed messages (the current functionality using ION Monitoring will remain). We cannot allow external control of administration tasks in MEC, which could potentially put extra strain on MEC. If something goes wrong that you can fix, we will notify you via Health Service. If you think something needs to be automated, create an ER for this with the business cases. All MEC automation will be managed within MEC.

/Nichlas

Legacy Contributor

The IECNofication BOD doesn't contain the needed information, which causes the ION Error BOD's segment to be too weak. Handling errors is therefore very hard.

We've tried to do some type of drillback solution bases on an ION Monitor that grabs the IECNotification BOD, which works with alot of hacking. However, in order for this Monitor to work good, we need to present way more information about the error, currently the BOD contains too little information.
I appreciate the IECNotification BOD as it solves a part of my problem, but I need the ability to do changes to this mapping, which is currently prohibited.
Exposing an API that returns the failed mapping would help alot, the result could contain the full error, the manifest, etc.

Instead, I've created a custom mapping that triggers when a message fails, this integration grabs all the possible Manifest information and sends a big error message to ION, from there I can route the errors to different people depending on data from the manifest.

Another case is that we want tracking possibilities from different places, for example, when an order is expected to be delivered to a 3rd party through IEC -> ION -> Connection Point, then it would be great to have an API that allows you to search for messages in IEC by custom manifest data.
Currently, the only manifest that is searchable is the map:partner, and that's only through the Advanced Search. This would be very helpful if we were able to do Advanced Search over an API.

Talking about Advanced Search.. We're missing the Custom Manifest configuration that was available in on-prem, if that could be implemented in Cloud, then we would be able to do pretty good drillbacks/automation links from various M3 programs or external systems.

And as the creator of this thread says, I would love to get APIs for the Redetect/Retry/Verify buttons, by doing this we can create powerful Workflows without the need of involving a technical resource everytime a mapping fails.

All other services in Infor, or atleast ION, Data Lake, Coleman, API Gateway etc has alot of APIs exposed which allows you to have full external control, so I wouldn't agree that we couldn't have external control over IEC as it obviously exist for every other services.

The same goes with EventAnalytics (List, Create, Update, Delete Sessions & Rules), EventHub (Search events), IEC Agreements (List, Create, Update, Delete agreements).

fredericlebars

Hello,

Business Case : During the Integration of an EDI ORDERS message we have an error in MEC treatment because customer or adress GLN does not exists in CRS885. We could trigger a workflow to alert business owner, the business owner fixes date issue in M3, Workflo validation retries MEC treatment.

Business-Technical case : We want to use monitoring tool (like ELK suite) to acquire logs from the different components in our information ecosystem.

Multiple goals :

Justifying information flows from source - target

Following messages for a businness data : For example we'd like to follow all messages concerning one order EDI ORDER in, WMS Print out picking, WMS Picking execution, EDI DESADV, EDI INVOICE.

...

Nichlas Karlsson

Hi,

Health Service notifications from MEC will provide a drillback link that takes you to the message view, where you can view logs, retry etc. We will only present basic error information in the Health Service notification, not logs, stack dumps etc.

It will be possible to filter emails in Health Service (and notifications in the UI of course). But then you need to have something to filter on, perhaps more than partner and agreement? We will consider this. What kid of data from the manifest do you use to route errors to different people?

To easier find messages we plan to provide searchable information that you can set in the mappings, for example Document ID and other information, including possible error message.

What is the business case for listing, exporting, importing and deleting sessions in Event Analytics and agreements i MEC via APIs? You can use Configuration Managements in CSSP to copy sessions and agreements between different tenants for a customer. I know that consultants may not have access to CSSP, then you need to talk to the customer. Public APIs for Configuration Management may be available in the future.

Browse Events for Event Hub will be improved with filtering (like in Event Analytics), easier viewing of elements etc. Why do you want to use an external UI or tool to search for events?

/Nichlas

Nichlas Karlsson

Thank you!

This is this type of input we want in the ERs.

So when a message fails in MEC a workflow should be triggered. I guess which workflow is triggered depends on the type of error. Then the workflow should be able to trigger a retry of the message in MEC.

We will discuss using external monitoring tools for the MEC logs. We are already looking at message and API statistics etc.

For the Portal adoption we will look at how to for example create widgets to follow orders, invoices etc. from source to target, and also how to navigate the system more easily, for example using context widgets to get between MEC and OneView for a message. I assume that you also want to use external systems to follow messages between different systems.

/Nichlas

Legacy Contributor

Hi!

Manifests:
We're adding our custom information in the manifest, such as ordertypes, potentially different "codes" depending on what API might have caused errors. As an example, if we have an order mapping that is crashing on MMS200MI.GetItmBasic, it's fair to say that we're missing the item, we'll then add some type of manifest that identifies "MASTERDATA", however, if the mapping would have failed on CRS610, the manifest could be set to CUSTOMERSERVICE.

What I mean with custom manifest is setManifestInfo("map:errorType", "MASTERDATA");

As a part of this, I have my custom error mapping that is initialized in "Error Processes", this mapping is the one that grabs all available manifest data and outputs an XML to ION for further processing.

Unfortunately, this can only be achieved with Ext4 XML agreements, as I'm not able to customize BOD agreements.

When the file enters ION I have setup a Business Rule matrix that looks at the Agreement name, the Mapping name, the custom manifests and routes to different IFS Distribution groups. (Through Workflows)

Searchable Information:
Regards to the searchable information I'd love to see the old on-prem ManifestInfo.xml file to get back, but preferrably with a nicer UI. If that gets implemented we would be able to do way more custom searches.

The searchable information (Searches towards the manifest) would be perfect for APIs, instead of transferring XML files between IEC and ION I could just grab the UUID or other manifest data from the error XML/BOD and fetch all the data i need from IEC over the APIs.

IEC Mapper:
Customers require more and more documentation, and IEC is a big part of it. a mapping is extremely time consuming to document, and together with the Agreement information, and the multiple EventAnalytics rules, the documentation could take a day to produce.

I have the requirement from alot of customers that wants me to document the API calls and the Java code from the IEC mappings. To solve this issue, I created an "IEC Documentation" service in the SDK that you can see an image of at the bottom of this comment.
If I were to have APIs to grab this information, I would have to manually upload the .map file, instead I could just fetch the mapping over the APIs.

EventAnalytics:
We offer customers support throughout all the Infor services, by having the ability to fetch an eventrule over an API you would be able to get better information in the Workflows that we use for error handling, we also implement other support services such as Jira and so on. If we were able to provide all of this things, such as the IEC error, the EventAnalytics rule, the EventHub TrackingId etc.. It would then be possible for extremely quick troubleshooting.

The majority of the people that works in support doesn't have all the access to these programs, usually these are M3 support(Not tech support), which would benefit alot if we also could provide them with the whole technical "Timeline" that led to the error.

EventAnalytics also works very slow, it can only enable/disable one rule at the time, which usually takes around 15 seconds per rule. It doesn't matter if I open up multiple EventAnalytics pages, because the EventAnalytics API seems to only be able to handle one request at the time, PER tenant.

The rules also load when you first click on the entry, which takes around 2-5 seconds, by creating our own H5 SDK we're able to do all the development faster, as we could queue these actions, use multiselect etc. Usually the big problem is when we import a session with multiple rules, we then have to start each rule, one by one.
By exposing EventAnalytics APIs, we would be able to customize our experience of the EventAnalytics service.

CSSP:
Our customers never do the deployment to PROD, that is what we are paid as a partner to do for them. Therefore, CSSP isn't a solution that we're able to use towards our customers. I haven't experimented with the tool too much, so I can't speak for the quality of the service. But as I understand, it's hard to use it as the type of exports always differ everytime a deployment to PROD should be done.

EventHub:
The EventHub list is bugging when you scroll too fast, it also returns 30 (or maybe 50?) rows at the time, using OOLINE as an example, it's impossible to use EventHub to find THAT specific event that we're looking for, because during that specific second there were 250 updates to OOLINE.

I appreciate that there will be better browse functionality to EventHub, but as long as the "Elements" column still is a semicolon-separated field, it would still be very hard to use the tool effectively.

H5 SDK:
I do have an H5 SDK application that helps me with alot of the things above, but its a quick & cheap solution that uses public APIs, and in some cases the "hidden" EventAnalytics APis etc. This SDK is developed because of the problems above, monitoring, troubleshooting, searching etc is not sufficient in todays Cloud environments.
I would also create a page in the SDK that gives me better control over IEC, but those APIs are way too strange for me to even try to use.

Finding the changed values in an UPDATE event from Event Hub:

Generating documentation from an IEC mapping:

Exported XLSX of the IEC mapping:

Sorry for the long comment, but there's alot of things that would get so much easier if we could have APIs exposed for the services that we use daily. I don't think that Infor needs to develop UIs for everything, the world is full of developers but we're close to nothing if we dont have the APIs to work with.

Phillip George

you got my vote!

Copyright © 2025 Infor. All rights reserved.