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.