By Alejandro Sosa-Oracle on Sep 18, 2014
Frequently, new functionality is created using the Business Event System or existing functionality is changed by adding new subscriptions, changing subscription phases, changing underlying java or PLSQL code, etc, and inexplicably it is found that raising the business event does not produce the desired result, as if the event was not raised.
The execution of an event consists basically of two parts: raising the event and do all required validation, and then finding the subscriptions to that event and execute them. The first one barely ever fails while the second one is more pron to issues and it is the one that we are mostly interested in as it has the code/behavior we want to see.
The following steps will allow to identify the actual cause of the issue by making use of the FND debugging options provided in EBS.
1. Adjust the subscription phase
Since subscriptions with phase higher than 100 are deferred you would need to raise the event on one session and then go to another session and debug it. It is easier if you can set the phase to a value lower than 100, say 99, and then raise the event in the session. This way you will be able to see everything the happens related to this event subscription, a nothing else.
Remember to ensure that the business event has an error subscription so that if something happens it does not go silent. By adding an ERROR subscription the system administrator would be able to see as notification explaining any failures. See here for more on error subscription definitions.
2. Raise the event
Do so either from the application or from java or PLSQL. Here is an example from PLSQL.
Note: you can make use of wf_log_pkg.init to enable the FND: Debug option for this session only, so there is no need to change the corresponding profile options. The last parameter ('wf%') means the debug is enabled for the WF code, which the BES belongs to.
declare l_parameters wf_parameter_list_t := wf_parameter_list_t(); begin --Optional: --execute immediate 'truncate table applsys.fnd_log_messages'; --Add your parameters here wf_log_pkg.init(1, null, 1, 'wf%'); wf_event.addparametertolist(p_name => 'NOTIFICATION_ID', p_value => '123', p_parameterlist => l_parameters); wf_event.raise(p_event_name => 'oracle.apps.wf.notification.send', p_event_key => '123', p_event_data => NULL, p_parameters => l_parameters, p_send_date => sysdate); commit; end; /
anonymous block completed
3. Find the logging details
Now, within the same session check the log messages generated by the Business Event System:
SELECT 'Level: '||log_level|| ' Module: '||module|| ' Time: '||to_char(timestamp, 'DD-MON-RR HH24:MI:SS')|| wf_core.newline|| '>>> Message: '||message_text FROM fnd_log_messages WHERE audsid = sys_context('userenv', 'SESSIONID') ORDER BY log_sequence /
The final lines found in the query above and the error notifications sent to the system administrator will point out to the error causing the event to look as it did not fire.