XtendM3

potatoit

2 months ago

Over the last few weeks I’ve been working on refactoring some extensions. A couple of these have been XtendM3 extensions and I thought I’d share some of my experiences.

For those of you that haven’t come across XtendM3 before, it is a M3CE technology that allows us to change the behaviour of the M3 Business Engine. It allows us to hook in to exit points within the M3BE code and manipulate results, it allows us to read and write directly to the M3 database, create new tables and create new APIs. XtendM3 extensions are written in Groovy which is a language based on Java. This is a technology that runs on the server.

Because this code can manipulate M3BE directly there’s a few things that currently have to be done.

You have to request that XtendM3 is enabled on your tenants
To deploy your XtendM3 extension to your production tenant, you must have it reviewed and signed by Infor. Though I had a very quick turn around on my development, I would suggest that if you are estimating timelines, it would pay to add buffer incase you need to rework

This of-course is on top of writing good code 🙂

This post focuses really on my recent experience using a trigger.

General

The first thing that I’ll say is that the Xtend team have really put a lot of work in to making development and source control really easy, take advantage of the resources that they have provided 🙂

Source Control

Source control is important for version control and generally should be used. It is currently required for signing. You can clone the Xtend teams example repository at https://github.com/infor-cloud/acme-corp-extensions

Logging

Those of you that have read my posts in the past will know that I’m a big fan of logging information on the code execution, especially when it is challenging or not possible to use debugging. But with XtendM3 we are logging in to the BE logs, the BE logs that are monitored by CloudOps (can you see where this is going? :-O)

During the process of uplifting an extension and running a fair amount of logging to troubleshoot a couple of issues I ended up getting an email from CloudOps about why there were all these warnings appearing for the tenant I was working in (I’m pleased I wasn’t using error logging :-)).

The lesson here was, be sensible with the logging – when tracing you are better off logging at an info level, and be very conscious that if you use warning or error levels a lot then you will probably end up in a discussion with the cloud team.

Triggers

Some programs in M3 have extension points which allow for you to override specific methods in M3, this could be so you can add your own custom logic on returning a value. One of the key things about triggers is that they have to be exposed to the framework by M3. At the moment, if you don’t have an exit point in a program, you can request one gets added.

You can see the extension points on a specific program by looking in Metadata Publisher – there is a section called “Extension Points”. Taking a look at PPS912 we can see that there are extension points that allow us to trigger off calls to get the Purchase Price, the Purchase Quantity, Status Supplier and several other functions.

There are some considerations (this is not an exhaustive list by any stretch) when using these extension points that I came across that gave me some odd results when I was iteratively working through some XtendM3 developments

When you make changes to your extension, close the program session that you are testing with to ‘load’ the changed code. This meant essentially ‘closing the tab’.
Extensions are per tenant, if you are developing and testing in a tenant where there are other companies or users working, consider adding some temporary code to limit the testing to just your user or if you have exclusive access to a company, limit the code execution to that company. I had someone working in a tenant that had a lot of users, they made a change which created a warning and created a lot of confusion for the users trying to test normal M3 functionality.
Don’t forget that some programs get called by autojobs – I got caught out with the logging where I thought I had removed it, but CloudOps sent me an email indicating the logging was still active – it turns out I had to restart one of the auto jobs (MNS051) for my updated code to be made available.
The extension point may be called multiple times by a M3 program naturally; if you are taking an incoming value, adding another value and returning it, then you need to make sure that now, and in the future you don’t end up adding your value multiple times because the internal code of M3 calls that function more than once. This may involve keeping track of the number of times you have been run in a session.
Be conscious that M3 is now getting additional functionality added on a monthly basis, especially when you consider the point above, today in the normal sequence of events, the extension point may only be called once, next month there may be functionality added when it gets called multiple times
Clean and robust code – make sure your code is clean, tidy, robust and thoroughly thought out, especially if you’re going to be using this for production. Because you are working at a low level and because M3 is updated each month, it is really imperative that you think long and hard about the implications of what you are doing and whether or not it will get approved and signed (see the link below for the approval requirements)

Getting the Code Signed

There’s a link below with the approval requirements. There’ s a few hints to make the process a little smoother

Keep the code clean, remove dead, commented out code
Make sure your inline comments make sense so the review team can understand what is going on, clean up any comments which aren’t needed or relevant
Check your logging, if you log a lot (like I generally do during development) you may be asked to tone it down
Provide JavaDoc comments, making sure you break your code down in to functions/methods that make sense and allow you to effectively describe your code