I’ve been pretty quiet for a while now but I felt it was time to dust off the wiki and share my thoughts about this brave new world…
I’ve been working with M3CE as my focus for the last 20 odd months. This has been working with customers whilst the product has been under controlled availability, defining consistent post-provisioning actions and working with some of the first 13.x to M3CE upgrade customers.
Though a lot of this blog has been around Smart Office and Smart Office scripting, you’ll probably all know that that wonderful piece of software isn’t available for M3CE :-(. So this will switch gears in to other more M3CE related topics. Even though I’m not employed as a developer, I’ve done a fair amount of exploration around H5 scripts and shall share some of my observations in the coming posts. (Happily I can say that I’m pretty happy with how H5 scripting has matured over the last few years.)
I’ve also done a lot of work around ION, Data Lake, ION APIs and general interfaces. And I have consistently been seeing assumptions from ‘the old way’ (otherwise known as bad practice :-P) being applied in M3CE which has caused headaches or not achieved the desired outcomes. I plan on sharing my observations and thoughts on this as-well.
When I first got my hands on an account for M3CE in August 2018, I can admit I was alarmed – there were decisions that I really didn’t like and a very significant lack of visibility on what was happening in the background – it’s hard letting go of the logs and being able to issue select statements directly against the database 😀
But at the same time, I was also really happy to see that decisions had been made around M3CE to protect the infrastructure that I had argued at length should have been in-place for M3 Single Tenant Cloud.
Being able to get a freshly provisioned M3CE tenant and having the ION APIs just work, IDM just work, and with minimum configuration have data pushed in to Data Lake, App Builder running, documents archiving in to IDM, really made me very happy. It’s what I had expected with Single Tenant but in my experience never really manifested.
It’s been a very interesting journey so far with a lot of interesting things happening and continuing to happen.
Stay tuned for more 🙂
As M3 has evolved it has become more complex. There are more components to monitor and though the grid has improved and provides easy ways to look at the logs there are a lot of logs to look at and a lot of information to digest.
Taking a look at IFL there’s what, 1, 2, 3, 4…oh really…far too many components to examine. And I am far too lazy to go through each one 🙂
They aren’t a great example because there isn’t much going on in the warning/error department, however some other customers have a lot in a lot of the grid applications.
The other issue is that it starts to get hard to correlate events between the different grid applications. One particular issue for a customer had a key event which caused a cascade of warnings and errors through other grid applications making the logs look pretty scary.
Though there are usually ways around this, I often need to add additional fields to panels – then I need to determine if we are in display mode vs. change so I can prevent the user from making any changes.
In the past, I’d look at a another control on the panel and determine if it was enabled or not and use that to enable/disable my control. It’s pretty crude and I’ve never really liked it.
As part of the removal of the modifications from IFL, I created a panel which allowed us to store and edit a number of settings through a custom panel called the “Vessel Panel”
A nice and easy little C# program that wasn’t terribly fancy. But it was still storing data in the modification tables.
When we upgraded to 13.4, we were also moving from Infors Upgrade-X to CloudSuite, this meant that the modification tables we were still storing data in were a no-no so I needed to move the data in to the customer extension tables and tweak all of our reports. At this stage I figured I’d be clever – not only would I cache the ports (PLACES), and Suppliers on panel load so the user didn’t have to wait for them to load when selecting, but I’d also load them concurrently so the user didn’t have to wait until the relatively slow Suppliers list had been retrieved before they could interact with the panel.
Worked a dream when I developed it and through UAT – we had one issue where it didn’t populate the panel correctly but we couldn’t replicate so put it down to a transient issue.
IFL has been running 13.4 for some months now, and given what’s not being said about Smart Office in a couple of the conferences earlier this year, I felt it was time to investigate migrating scripts to H5.
Previously, I had been reluctant to pursue this because H5 really lacked maturity and for the majority of our users, Smart Office is just easier to use. The last time I did some serious work with it, it felt like whack-a-mole with bugs and functionality. But we’re now more than a year further down the track and it’s clear that there has been a lot of focus put on H5.
Many years ago I created a little Mashup that called a MWS SOAP WebService to return invoices for a supplier on a specific day. More recently IFL updated to 13.4, and as part of the 13.4 upgrade we moved to SAML based authentication. Moving to SAML meant that our userbase needed to provide our AD domain name aswell as their username to log in. Not a big issue.
However, requiring the domain means that the authentication of the Mashup SOAP call to MWS now fails. There were some other gotchyas which were I believe unavoidable at the version of Smart Office we were on originally, but I could now address properly.
The running Mashup looked like this
The user keys in the suppler, and then the date and finally clicks on Lookup.