EBS: Application message changes not reflected?

Oracle Applications use messages to communicate with users. Typical messages include warnings and error messages, brief instructions, and informative messages on self-service pages, progress of concurrent requests, work done and anything else of interest or helpful to users.

It’s very common for developers to modify the AOL messages. Sometimes, it’s frustrating, when an it is modified and changes are not reflected as expected. This is the most common hurdle, for developer dealing with FND messages in combination with Workflow/AME. Clearing application cache and even apache bounce may not reflect the changes in workflow process. Newly created messages may not have this problem and reflected in application without any problem. If you are also facing such problem, this article might help you, keep reading…. :-)

Before we learn how to solve this problem, here is a quick introduction about AOL messages. Information about AOL messages is stored in three different repositories, each of which has its own format and significance.

1) Database: When you navigate to Application Developer -> Application -> Messages form and edit the changes, they are saved directly to database. Table name: FND_NEW_MESSAGES

When you query an AOL message with PLSQL functions, FND_MESSAGE.set_token or FND_MESSAGE.get etc…, most likely it returns the latest message changes because, it directly hits database.

2) Runtime: A runtime binary file stores the messages for a single application and a single language. The file is optimized for rapid lookup of individual messages by message NAME. For example, all Human Resources, English language messages are stored at 

$PER_TOP/$APPLMSG/US.msb aka $PER_TOP/mesg/US.msb

When you change a message via application developer -> messages form, corresponding .msb file is not updated automatically. You will have to run “Generate Messages” program for a specific language and application with a specific option of “DB_TO_ RUNTIME”. This would generate and replace the .msb file with the latest contents. Generally, OC4J OAF pages use the .msb files, for message lookup and fetching the message text. So, running this concurrent program and clearing global application cache via functional administrator, should reflect the new changes. 

3) Script: Messages stored in .msg files. Usually, not used by application but used by developers and DBAs to transfer messages from one instance to another, especially during upgrades and migrations. Once the msg files are copied to new instance, “Generate Messages” concurrent program should be run with eighter “SCRIPT_TO_DB” or “SCRIPT_TO_RUNTIME” options, which would eventually load the messages to database or msb file. 

OK, enough of theory, let’s discuss the actual problem, message changes are not reflected in workflow processes. Workflow process maintains it’s own version of AOL object cache and won’t reset upon clear application cache and OC4J server bounce. That’s why, even a PLSQL function to get FND message that is part of workflow process will return the cached message text.

Try the following steps in the same sequence to reflect the new changes in workflow/AME process.

a) Changes to AOL message via application developer

b) Run “Generate Messages” with “DB_TO_RUNTIME” option and make sure US.msb file is overwritten at $PER_TOP/mesg (path for human resources for example)

c) Navigate to System Administrator -> Concurrent -> Manager -> Administer form and query for “Workflow Agent Listener Service”, click on Restart button and wait for it complete. If it is struck at restart, click on Activate button to re-activate. This would clear the workflow AOL object cache and should reflect the latest changes.

d) If the message changes are still not reflected, don’t blame me… just not your lucky day today, go for apache bounce and try your luck. :-)

Did that help? Or want to correct/add something, please write a comment below.

Reference: Message Repositories

Cheers

Suresh