You could use Transaction_SYS.Log_Status_Info method to add information to the background job for trace purposes.

Transaction_SYS.Log_Status_Info('<Enter your text here>', 'INFO');

The text you enter will be logged here, even if the background job fails:

Hi @Tomas Ruderfelt 

Thanks for taking the time to answer my question. I am afraid I didn’t use the right word to describe the type of execution I’m trying to run. The exact code I’m running is an Event Action, so technically it doesn’t run in the foreground but only when (in this case) the CUSTOMER_ORDER field STATUS changes to “Released”

​

As you can see this is not, strictly speaking, a Background Job (now I realize the title of my post was confusing) but rather a task that will not happen in the foreground which is not categorized as “Background Job” in strict IFS terms.

What I mean by this is, if I release an Order, that status changes and this Custom Event Action is triggered, yet if I have my Debug Console open and place a TRACE_SYS.Message statement here, it is not showing up.

Hi @msurasky-price 

It’s bit unclear what you meant by task that will not happen in the foreground. Transaction_SYS.Deferred_Call will generate a background job and you can monitor the details in IFS background jobs.

In order to put traces, you can use the method which @Tomas Ruderfelt mentioned in your code (Pi_Pricing_Rule_Util_API.Pricing_Rule) and the messages will appear in the background job details page as shown above.

Hope it helps :)

Damith

I see @dsj, now it all makes sense.

I didn’t know that Transaction_SYS.Deferred_Call will generate a background job that will be displayed in IFS like any other regular background jobs.

With this info in mind, I’ll continue by logging the using @Tomas Ruderfelt solution

Thanks all for your help!

One more for you @dsj  and @Tomas Ruderfelt  

After my testing, I did confirm that the TRANSACTION_SYS.DEFERRED_CALL creates a Background Job. What I don’t understand is how to write the INFO Message inside the right Job by using TRANSACTION_SYS.LOG_STATUS_INFO.

I mean, I do see that the LOG_STATUS_INFO message I created was “written” in a Job 

The problem is that, in this case, this job (Job 80256987) was NOT the job executing the procedure… the job executing the procedure didn’t get any text!

I did notice that the LOG_STATUS_INFO procedure starts by getting the “Current Job ID” by calling GET_CURRENT_JOB_ID… but then, why is it not getting the right one?

Hi @msurasky-price 

I haven’t check the Transaction_SYS code on how it gets the current job ID, but it could be due to that Get_Current_Job_Id is getting the value from the user session.

define the event action block as a autonomous transaction to see if it does the trick ;)

DECLARE

PRAGMA AUTONOMOUS_TRANSACTION;

It is also impossible to say without knowing the details about the customization and events.

Is it 100% sure that the event you have created is not triggered by the first background job?

If this is a test environment you might raise an error in the event and then you might find the call stack of that error.

Thank you @Tomas Ruderfelt. The event I have created is triggered by a change in Purchase Order status (from Planned to Released). Having said that, with a bit more testing done, I have noticed that the INFO message placement is not consistently on a different Background Job, sometimes it goes to the right job, sometime it doesn’t… 

I’m not overly concerned about that because I can always go to the base table  where messages are written (TRANSACTION_SYS_STATUS_TAB) and no matter “where” the message is placed, I can find them there.

You guys are great, thanks for all the help and support. I hope I can “pay it forward” by helping others in this community!

@msurasky-price  Definitely not recommending this approach but it will work consistently…

DECLARE
    job_id_ 	number := NULL;
    attr_ 		varchar2(32676);
    sql_msg_ 	varchar2(32676);
    stmt_ 		varchar2(32676);
    queue_id_ 	number := 10;

BEGIN
	stmt_ := q'=
		DECLARE
			inside_attr_		VARCHAR2(32000);
			info_				VARCHAR2(32000) := '';
			CURSOR get_order_lines IS
				SELECT 1
				FROM customer_order_line
				WHERE order_no = '&NEW:ORDER_NO'
				AND contract = '&NEW:CONTRACT'
				AND demand_code_db IN ('IPD','IPT')
				AND supply_code_db IN ('SO','DOP','IO')
			;

		BEGIN
			Client_SYS.Clear_Attr(inside_attr_);
			Client_SYS.Add_To_Attr('CO_CONTRACT_','&NEW:CONTRACT', inside_attr_);
			Client_SYS.Add_To_Attr('CO_ORDER_NO_','&NEW:ORDER_NO', inside_attr_);

			Pi_Pricing_Rule_Util_API.Pricing_Rule(inside_attr_);

			info_ := 'Event PRICE_PRICING_RULE: ' || inside_attr_ || '.' ;
			Fnd_Context_SYS.Set_Value('ERROR_FORMATTED_KEY', SUBSTR(info_, 1, 2000));
			Transaction_SYS.Log_Status_Info(SUBSTR('Sever Side', 1, 2000), 'INFO');
		END;
	]';

	sql_msg_ := Message_SYS.Construct('UPD');
	Message_SYS.Add_Attribute(sql_msg_, 'SQL', stmt_);
	CLIENT_SYS.Clear_Attr(attr_);
	CLIENT_SYS.Add_To_Attr('SQL_DATA_', sql_msg_, attr_);
	CLIENT_SYS.Add_To_Attr('MSG_', '', attr_);
	Transaction_SYS.Deferred_Call(
								job_id_,
								'Fnd_Event_Action_API.Action_Executeonlinesql',
								'PARAMETER',
								attr_,
								'Update PO and CO Lines Prices of Int Purch Dir',
								sysdate,
								'FALSE',
								queue_id_
	);
END;  

There are way better approaches but as you’re are still in APPS10 and events will be “going away”… 🦴 , I remember utilizing this pattern once or twice...theres a scheduled task and a batch queue to setup as well