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.
A few weeks ago I did a presentation at the Australia/New Zealand User Group meeting on the Gold Coast to really discuss that the M3 Grid Applications shouldn’t be as intimating as a lot of people find them, as part of the presentation, I also touched on monitoring. One of the points I had raised was monitoring Event Hub, some of you may have had the misfortune of seeing what happens when a subscriber can’t connect and we have a large number of events get queued (for example, through a mass change or through data loads) – and have had fun trying to recover when you run out of disk space.
One of the questions that came out after this was around the monitoring of Event Hub and how to check its health and the queues. At the time I wasn’t 100% sure on how it could be done from the grid. We can of-course monitor disk space and there is a /persistent directory on the file system that we can monitor but it’s a little clunky.
I’ve had a look and the good news is that there appears to be a Rest API from at least 2.1.9 which provides us with the information that we need in a json format.
Recently I did some work where we wanted to add a second ListView to a panel. We wanted to keep the ListView consistent with the look and feel of M3 ListViews but we were constrained with space on the panel, so I didn’t want the giant header we have in a normal ListView.
Normally, we’d just set up a new Style and use the BasedOn keyword to point us back to the M3 style. But well, JScripts don’t really lend themselves to XAML very well or so I thought! And to think I had spent so much time over the years trying to get this sort of thing working programmatically.
I stumbled across a the mention of that functions I’d normally explore on MSDN were depreciated and I should be looking at XamlReader (https://msdn.microsoft.com/en-us/library/system.windows.markup.xamlreader(v=vs.110).aspx) to create my styles so I did.
Over the years I’ve used a variety of methods to call things like PageDown from within my scripts, some more pretty than others.
You would think that in the Init() you can just call controller.PageDown() and all is good in the world.
var gDebug = null;
var gController = null;
var gContent = null;
public function Init(element: Object, args: Object, controller : Object, debug : Object)
gDebug = debug;
gController = controller;
gContent = controller.RenderEngine.Content;
And if you test with the Script tool within Smart Office it is…until you deploy it and then you get the “Duplicate request skipped” message in the logs 😦
I have a project that I am working on which involves the need to set the ListView filter fields.
Back when I was much younger and far more naïve 🙂 I would brute force my want to locate the control (https://potatoit.kiwi/2010/10/10/manipulating-smart-office-column-header-filter-values/). Years later I saw the light and stumbled across the fields but I didn’t ever get around to posting about it. Of course, I couldn’t remember where I had found the fields nor could I find a posting about it on my blog so I did some investigation.
I also wrote some code around exploring what I thought was the appropriate field list and expanded that as it became more apparent that I was on the right track, until finally I wrote some functions to test that I would actually use.