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.
Roll on day 2 of go-live. Suddenly I’m getting multiple reports where only portions of the panel were loading and error messages would pop up. They started getting frequent.
The Smart Office logs showed a rather baffling error message
Now we are using the built in API interface within Smart Office. We shouldn’t be getting any issues with user names.
I tested each of the API calls one after the other and couldn’t replicate so I wondered if it had something to do with the calls being called concurrently. I wrote a little program which call the 3 APIs that I was using. I would create three individual background workers. When the Start button was clicked it would check which of the three calls were selected, then of those three calls it would check to see if the background worker was already running, if not, it would run the background worker.
I then just channelled my horizontal scroller game days and set about clicking start as quickly as I could 🙂 and would eventually get something like this:
Load CO uses the customer extension table APIs, Places was a CRS990 call and Suppliers the CRS620 call.
I could consistently get the issue to occur at least once every 10 clicks.
I now had a little cut down program that could be used to demonstrate the issue, so I logged the issue. And given the nature of the issue I was expecting it to be an absolute PITA convincing support that it was an issue and getting it pushed back to development. But, I was really lucky and Dinno from support picked up my case. Interestingly he got me to set the processor affinity to a single processor, when I did this I couldn’t replicate the issue (curse you multi-proc world! :-)).
Long story short, I was on Smart Office 10.2.1.0.210, now build 10.2.1.0.265 which has just been released looks like it has resolved our issue.