Then, the challenge becomes how to get that data back into M3.

Sure, there is limited ability to perform mass updates in CRS800, but often users come up with a process where they get information out of M3, manipulate it however they like in Excel, and then run into a roadblock trying to get the data back into the system. Nobody wants to manually key in hundreds or even thousands of records, but waiting for IT to develop a robust interface can take months.

In my personal experience, I have tackled this issue at pretty much every ERP installation I’ve worked with. It could be as simple as “we need to change the buyer assigned to this list of suppliers” to “we need to add X weeks to the lead times on parts from Supplier Y for a few months, then change it back later on”.

So what to do?

Excel VBA + Infor M3 API to the rescue

Excel is easily extendable by using VBA (Visual Basic for Applications) code behind the scenes, creating macros that call M3 APIs to get data out of the system or load it back in. One can even perform many common business process tasks by stringing multiple API calls together.

The benefit there is that you are using ERP functions to process your data just as if a user was working within the system, so all of your business logic is still being respected. You aren’t simply slamming records into a database, you are following established procedures, but with the ability to do so in an automated way.

So how to connect Excel to M3? In the past, you would download the M3 API Toolkit from Infor, and install software on each computer which would connect to M3, which was a hassle. Installing .dll files and registering them within Windows could be a real pain if not done correctly. And especially for newer, multi-tenant CloudSuite implementations of M3, the old toolkit really isn’t an option anyway since you’re not able to create socket connections to the M3 server.

Using REST API With Infor M3

Thankfully, we can use REST APIs to make those connections instead. With a REST API call, the communication functions much like your web browser following a link – you sent a string to a server in a URL, and get back information in return.

There is no additional software to install, and when the user makes their first API call they will be prompted to provide a user ID and password, just as if they were logging into M3. For a primer on calling M3 APIs using REST, check out this blog post over at M3 Ideas.

The idea here is that within Excel you will create a URL that is used to make the call to M3. The URL is a web address just like you see at the top of your browser, but it will refer to the M3 environment and API program you are accessing, and include any parameters you need to pass.

For example, if you want to get the item master information for item number ABC123, your URL might look like this:

https://[server]:[port]/m3api-rest/execute/MMS200MI/Get?ITNO=ABC123

The [server]:[port] portion will relate to your individual implementation (each environment will have its own values there), and you can see where the API program (MMS200MI) and transaction (Get) fit into the mix. From there, you append parameters to the end of the URL, such as “&CONO=123” for adding Company Number = 123 as parameter.

Calling REST API from Excel VBA

OK, so we know we have to create a REST API call against M3, but how do we do that from Excel using VBA? First off, you’ll want to make sure you add the Microsoft XML v6.0 library to your VBA references, like so. This gives you the necessary objects, methods and properties to make the REST API call and deal with the XML you will get back from M3:

For an example of how the VBA code looks when making the API call, take a look at the following. At first we set up the objects for the API call (objRequest) and the response we receive back from M3 (xdoc), and then make the call in the line that begins with “.Open”. The variable strURL is a string with the URL defined as we’ve noted above.

Set objRequest = CreateObject("MSXML2.XMLHTTP")
Set xdoc = CreateObject("MSXML2.DOMDocument")
xdoc.async = False
xdoc.validateOnParse = False
blnAsync = True 

With objRequest
     .Open "GET", strURL, blnAsync
     .setRequestHeader "Content-Type", "application/json"
     .setRequestHeader "DateTime", Now
     .setRequestHeader "Cache-control", "no-cache, no-store"
     .setRequestHeader "pragma", "no-cache"
     .setRequestHeader "If-Modified-Since", "Sat, 1 Jan 2000 00:00:00 GMT"
     .Send
     
     While objRequest.readyState <> 4
         DoEvents
     Wend
     xdoc.LoadXML (.ResponseText)
 End With

What you can then work with in Excel VBA is the xdoc object, which contains the XML response from M3.

That’s enough to get you started, I will follow up with more posts covering how to deal with the output received from M3, along with a few tips and tricks I’ve learned along the way while creating these Excel-based tools that interact with M3.

Did you enjoy this post? Go ahead and connect with me on LinkedIn or email me (dirkhoag at gmail), making sure to include a message so I know how you found me! If you could use some assistance with Infor M3 (functional or technical), I am available for remote, part-time consulting. Just send a message for further details!

The post Calling Infor M3 APIs from Excel appeared first on Ready ERP Solutions.

As if this wasn’t exciting enough (calm down, people!), stick around to the end for a key tip on how to make sure you can process hundreds of orders in a timely fashion, and avoid a common bottleneck that could leave your M3 system choking on large volumes of orders!

Infor M3 Customer Order API Overview

When customer orders are loaded into M3, they begin as “batch” customer orders, which can be seen in OIS275. They don’t actually hit the books as real orders (which impact sales statistics, material plans, etc.) until they go through a confirmation process that validates the data, at which point you will see them in OIS300, the Customer Order Toolbox.

Assuming you already have the data you need (i.e. proper customer numbers, item numbers, and more), there will be three API transactions you will call in sequence:

1. OIS100MI.AddBatchHead
2. OIS100MI.AddBatchLine
3. OIS100MI.Confirm

Whatever program you are using to load your customer orders, first you will set up some looping logic to follow these steps. Let’s say you have a file like the following, with multiple orders, each of which may or may not have multiple lines:

order1     line1
order1     line2
order2     line1
order3     line1
order3     line2

The looping logic you will need to read through this file and load M3 will proceed as follows:

1. Call AddBatchHead each time you encounter a new order number (you will receive back a Temporary Customer Order number)
2. Call AddBatchLine for each line (refer to the Temporary Customer Order number from Step 1 so the line gets added to the correct order)
3. If the next line marks the end of the file or begins a new order, then call Confirm to submit this Temporary Customer Order for validation

So far, this should all be fairly straightforward, but there is an important design consideration that comes along when we get to that Confirm transaction.

M3 Batch Customer Order Confirmation – Interactive or Batch?

When it comes to confirming the Temporary Customer Order, you have a choice between Interactive or Batch processing.

With Interactive Confirmation, M3 will process your order immediately upon receiving your API call, which means you will likely have to wait several seconds to receive the response message. That return transaction will come back with either “OK” followed by your new Customer Order Number, or “NOK” with a status code that is associated with various issues that come up during validation (error in the header, error in the lines, etc.). If you are calling these APIs from another system where you need that response and are dealing with low transaction volumes this may be the appropriate choice.

In Batch Confirmation, M3 will immediately come back with an “OK” response (assuming you have passed a valid Temporary Customer Order number), and the validation process will take place in a separate batch job within M3. Your API process will not receive back the ultimate Customer Order Number that results from the confirmation, so in this case you will need a separate process to follow up and make sure orders aren’t getting stuck in OIS275 due to validation issues. On the upside, upon receiving back that “OK” you can immediately move on to your next order, so this works better for high-volume situations where you need to load multiple orders in sequence.

How To Speed Up Batch Confirmation For Multiple Orders

During one project we had a requirement to get hundreds of customer orders (with hundreds of lines each) processed all the way through to the point where picking lists being released to the warehouse within a narrow time frame. When we fired up our API process the batch orders were pushed into M3 in a timely fashion, but the confirmation process became the bottleneck.

As we refreshed the view in OIS300 to see how the orders were proceeding through the system, we saw that only 10 orders were being processed at a time (each taking as long as a minute to go through the process of confirmation, allocation, and picking list release). We knew that would never meet the business requirement.

That’s when we took a look at the batch processing setup within M3.

By default, the confirmation jobs will get filed in the QBATCH job queue, with one batch job per Confirm transaction. Typically M3 installations have the QBATCH queue set to allow 10 active jobs at a time, so that is why we saw only 10 orders being validated at once.

In MNS300, however, you can adjust those settings for job queues. We tried bumping it up to 15, and sure enough, overall processing time improved. We then tried 20, and 25, and by that time we were easily beating the business requirement, achieving a 90% reduction in processing time as compared to the client’s existing legacy system!

At another client, I created an Excel-based tool to take data from one system and create Customer Orders in M3, replacing a manual process that had two people keying information all day long into a macro-based function that took one person less than 15 minutes to load, process and confirm the resulting data (which was also much more accurate due to the elimination of manual entry).

This adjustment of the “Max active jobs” setting on the batch job queue allows M3 to create additional separate threads to process these customer orders, which has a tremendous effect on performance when you are working with high-volume situations. Finding the most appropriate number of Max Active Jobs for your implementation could be an exercise in trial & error, like we did in the example above, but you should also consult your system administrator or M3 technical consultant. Obviously if you try to spin up hundreds of threads at once that would present its own complications.

Key Questions To Ask Yourself

If you are planning an Infor M3 customer order API interface, asking yourself these questions can help inform the choices you make in creating your API calls:

• What is the anticipated volume of orders being submitted in a given job? Will this interface process many orders in each blast (batch), or individual orders several times throughout the day (interactive)?
• To what extent can error correction be done by the user or system that is submitting the data? Would providing them with error messages coming back from M3 and allowing them to resubmit be helpful (interactive), or should those be managed on the M3 side (batch)?
• Does your system already have many batch jobs typically running during the day, and would it make sense for a batch load of customer orders to run behind the scenes at a lower priority? If so, consider creating a new job queue and assigning the batch order confirmation job to it in MNS300/MNS310 with its own “Max Active Jobs” setting and priority value, so the orders can load without negatively impacting other users or processes.

Do you have any questions about the Infor M3 customer order API process, or dealing with APIs in general? Feel free to sound off in the comments below.

Note: If you enjoyed this post and could use some assistance with Infor M3 (functional or technical), I am available for part-time after-hours Infor M3 consulting! Please email me (dirkhoag@gmail.com) or contact me on LinkedIn for further details!

The post Infor M3 Customer Order API Processing Tips appeared first on Ready ERP Solutions.