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.
Cheers
Suresh
