Recently I was involved with a project where the customer was having some issues where they had added some fields to MWS435PF. They added OACUOR from the OOHEAD table and whenever they ran the report they would get a message saying ___ERROR___ instead of the data

The eagle eyed will also notice that the date looks a little off as-well.

When the XML is generated, if there is bad data / illegal characters for the XML then the bad data will be substituted with a ___ERROR___. This should be relatively easy to track down. You have an order, you have an error – you look at the orders data…

In this case however, we would get this error regardless of what the customers order number had, be that blank or otherwise. It would also happen on every single order.

The odd thing was that if we reset to standard we would get our output, we add just these two fields and we get the error.

In another tenant we would reset to standard, add our two fields and we wouldn’t get the error. This would bias my thoughts to the issue being either a company specific setting or tenant specific setting.

Normally when examining this sort of issue, I’d be inclined to try importing the CMS005 configuration in to another company, ideally on another tenant. If we get the same issue, we know that the trigger is in our configurable XML import file. We also know that we have a good chance of being able to shuffle this off to support to replicate and get development to debug.

(Incidentally, if you open the exported .zip file, then open the XML file in the zip, you’ll see that these exports just run a sequence of API calls – and if you are having trouble with imports, it can be useful to manually step through each of the API calls).

In the tenant we previously added the two fields without getting an error, we imported the configuration.  Surprisingly when we then ran the output we got the error. So at this point we know that we can replicate the issue across tenants – it’s probably going to be something within the configurable XML itself.

And this is where it was puzzling – in this other tenant it had worked prior to the import, we reset MWS435PF back to standard and then added the two fields back in manually, now got an error. We had now ‘broken’ this other tenant. 😦

As it turns out, the autojob MWS972 caches configurable XML. If we reset MWS435PF to standard, then restarted MWS972, then added the fields we wouldn’t get the error. If we import the file, we would get the error. If we then reset to standard and added the fields we got the error.  The key being that if we generated the output after the import, then reset to standard, the error would persist with those fields until MWS972 was restarted.

As the investigation progressed, it was discovered that the CIDDRA table had been added as a relate table with the prefix of OA. OOHEAD is also OA and it is part of the standard MWS435PF related tables. We shouldn’t be able to add two tables using the same prefix to our configurable XML (one needs to be given a virtual prefix), and there are warnings to prevent you from doing this. It is still unclear how the conflicting prefix was added.  But essentially the error was being caused by trying to read the OACUOR data from a CIDDRA data object. And because this was bad data, it wasn’t flushed from MWS972 properly until the autojob was restarted.

Once the customer added a different prefix for the CIDDRA table, this issue disappeared.

I found this particular issue really interesting because we got very unexpected behaviour that left us scratching our heads as to what was going on.

Happy issue hunting!