InforM3MIBulkv2 - Usage Limits & Parallel Requests

I'm in the process of architecting an integration from M3 to a web shop and there's a big discussion around pricing. Ultimately it boils down to two schools of thought.

1. Do you export pricing, discounts and promotions on an event basis either through event hub or streaming pipelines to the website, and replicate the pricing hierarchy in the web shop?

2. Does the web shop connect directly with M3 APIs to get pricing real time, with intelligent caching within the web shop. This method would need to rely on bulk API technology.

More questions will be asked surrounding other data requirements such as ATP. After looking at ION API Monitoring for a customer that uses Infor Rhythm, it looks like option 2 is utilized, although they use the pricing service web request, that has next to no documentation in its usage, or advantages to the standard M3 APIs M3/BDProcessor/ItemPricesService.

I'm leaning towards option 2. I believe the pricing data should only be stored once, pricing hierarchy with discounts and promotions is complex, so it's a risk having this logic maintained 2 systems.

I've built proof of concepts in NextJS where i can call OIS320MI.GetPriceLine in batches of ~25 and get response times of approx 1 second which is sufficient for the website. Whilst this is low for bulk apis, when i increase the batch size I notice the response times creep up to unacceptable threshold for a website.

I'd like to know peoples thoughts on calling bulk apis in parallel. Usage limits for this are not clear for this type of API, there's a lot of limits for ION but not M3 APIs. https://docs.infor.com/inforosulmt/xx/en-us/usagelimits/default.html. I'm talking core business engine technology and causing general system slowness by pushing volume through batch APIs.

Imagine the scenario where a website loads ~ 50 items on a page, using the above technologies I can get 50 prices back in approx 1 second. As the customer pages through the item list, more APIs are fired and provided I stay within the Infor OS Service Limits (starting at 250k APIs per day), i'm okay.

What happens if the customer wants to get an entire set of their pricing in a timely fashion. If there are 100k items, then using the above logic this turns into submitting (100,000 / 25) 4k bulk API requests in parallel. This is obviously an extreme scenario that I wouldn't recommend, but I'd like to know if anyone else has had similar thoughts around this, and what is an acceptable amount of bulk APIs to call in parallel? You could argue that a timely fashion isn't appropriate for this scenario and therefore the batch sizes should be much higher and use asynchronous batch technology to negate the 2 minute timeout policy for APIs. However, there's still the question of what is an acceptable amount of batch APIs you should call in parallel.

Back in the day I could manage this through LCM, and be clever in what service accounts could use what API subsystems and then it just becomes a memory / cpu question.

I appreciate web browsers will restrict the amount of parallel API calls you can make to prevent DDOS attacks, but i'm talking about using server side technology calling the APIs which are unrestricted in the amount of parallel API calls.

Find more posts tagged with

Comments

JuanSz

Hi Callum, interesting use case! Some thoughts.

Real time synchronous solutions are great for lower volumes but less for the volumes you talk about. User experience is in web shops number 1 priority therefore I would not rely on retrieval on the fly.
But at the same time you do not want to have detailed pricing models in two systems as you say already. The other day we built a solution where we used OIS538 price reports per customer group including order specific discounts. Since prices were valid for 3 months and there were 50 customer groups with 60k items, we were able to calculate every possible end price including discounts etc. in advance. Blow this to the web shop a couple days before new price starts. When the customer puts items in the shopping basket OIS320 was still used to retrieve real price.

If you have many "similar prices", caching in the webshop could be an option. This works great if you have many customers and many items but limited different discounts. You do need somewhat customer / item grouping logic in your web shop (but not full blown pricing model).
Currently working on a project we investigate the other way around. A separate pricing engine as part of the web shop application. The web shop "tells" M3 on an order what to price and discount to use. When an order is entered manually in OIS300, M3 request via an API call the price from that engine as well. But this design choice hurts my M3-heart

Please keep us posted on the solution you end up. Thanks!

magnus-tallqvist

As a side note to above. Getting back 50 prices in one second might be far from the truth. That might be true if only using a simple pricing setup but that is rarely the case. There is nowhere where people are as creative as when it boils down to pricing algorithms. As soon as you add more logic to the pricing calculations the response time will be drastically mush higher than above. On top of that you also need to think through the number of parallel people, each one looking at 50+ items in a list. The number of API calls are quickly multiplying. This is one of the integration areas where customers has the most issues with performance/number of API calls. We would highly recommend the below solution with pre-calculating the prices. That might not be a solution for all items/customers in the web shop so maybe you need to combine the two methods to get a good result.

CWRIGHT

Hi Juan,

Thanks for your insights on this. Arguably in this case, the webshop is more important than the ERP itself, so it's of the highest priority to get right.

Whilst the pricing is fairly static, the discounts are not and can be changed daily by the customer which throws monthly price validity out of the window I'm afraid.

Caching would be a really important part of this solution, but as the customer is B2B, the pricing model becomes quite complex.

Due to the importance of the web shop, we are looking at going down the route of exporting pricing / discount tables from M3 on an event basis, and replicating the pricing logic in the website by following a list of assumptions. Unfortunately, this is the only way right now we can guarantee the retrieval of bespoke pricing in a timely manner.

If the OIS320MI price retrieval was faster and the ION API limits were higher, I think this might have been a great solution but the uncertainties combined with the importance of the website, is preventing us from going down that route.

CWRIGHT

Thanks Magnus,

You're correct in that you can't assume the performance of OIS320MI without building it all and doing volume testing. Even toggles such as enable best pricing would likely impact as the entire pricing hierarchy has to be used, not just break out at the first match.

The API calls increase very quickly, when you start calculating all the price points you can quickly get into the 10s or 100s of millions.

However, when keeping this all at a really high level, the pricing in M3 allows you to get very creative which undoubtably relies on some complex business engine logic. Having to replicate that in external systems is a mammoth task unless you make some a list of assumptions, and agree the pricing hierarchy in M3 can never change without extensive redevelopment. Based on that point alone, it makes sense for M3 to be the pricing engine, but when you scale the volumes up and consider the performance and usage limits for live pricing, you struggle to make it make sense.

Copyright © 2025 Infor. All rights reserved.