AAKE v21: MSGTX table empty

[Michael A. Lowry]

We are in the process of setting up AAKE v21 systems in the cloud, and building integration with our existing applications. During a recent integration test, we encountered a problem with one of our applications because an SQL query it performs against the AE database was failing. This query fetches status information about active tasks in the Automation Engine, and we have been using it without problems for the better part of a decade.

After a bit of investigation, we discovered the reason the query was failing: in AAKE v21, the MSGTX table is completely empty.

Since version 11, this table has contained a copy of the data stored in the uc.msl file - a mapping table from status codes to status messages in English, French, and German.

KB article 233880 explains what happened:

Since AE 12.2 the table [MSGTX] has been removed because it is not used anymore by the core.

The structure of the table MSGTX is provided for compatibility purposes, customers still are using the functionality to query this table and to load the uc.msl directly into the database. We strongly advise the customer not to alter our database schema.

Indeed, customers are using this table, as one can discover with a simple search for "MSGTX" in this forum. We are using the table to speed up the process of looking up task status.

The MSGTX table is still documented in the AAKE v21.0 DB schema documentation, and its structure is still created as a part of the initial data load. However, the table no longer contains any content, so any applications that rely on it will encounter problems.

Applications that need to translate from AE status codes to the equivalent message text strings must implement a separate version of the table, imported perhaps from the uc.msl file, or must rely on slower methods such as the TranslatedMessage Java API class. (If there's a REST API for this, I wasn't able to find it.)

[Josef Scharl]

Hi Michael,

We discovered this issue back in January, when we set up a new UC4 environment in version 12.3.
We raised a ticket and got exactly this useless answer (same wording as in the KE mentioned above). Digging deeper we finally got this information from support:

this was removed because not used anymore by the core.

the customer can load the uc.msl to a db table and use it - or use the uc.msl file

So, we fixed it loading uc.msl file into the UC4 DB schema, please find more details in our internal documentation – attached below.

KR, Tscho

[Michael A. Lowry]

I have attached an Excel spreadsheet containing an excerpt from the v12.3.9HF1 uc.msl file corresponding to the English messages numbered 1005–1999. These are the task status codes mentioned in the documentation of the AbstractTask Java API class.

By the way, has anyone ever seen status codes 1005, 1006, 1008, or 1009 in the wild? I have not.

Number	Language	Type	Message
1005	E	C	Actually running
1006	E	C	Checked
1008	E	C	Aborted
1009	E	C	Done

Attachment(s)

uc.msl.xlsx   16 KB 1 version

[Michael A. Lowry]

In another thread, I posted a way to convert uc.msl into tab-separated values suitable for importing into a database.

[Andy Stetter]

Is converting the uc.msl a valid solution though if Broadcom will not support any modifications to the database?  What other options are there for customers so Broadcom doesn't use this as an excuse for not providing support?  Much like Michael's initial thread above my company was also querying the MSGTX table and then we migrated to AAE 21.x in where it is no longer being used.  We would monitor stuck job objects by querying this table every 30 minutes and take action accordingly if results were returned.  We're finding that deprecating this has been very painful for us as a customer.  

Has anyone tried the slower Java API class mentioned above?  Or have there been any new REST api's made available that would be much easier to use?