Solved

How to trace background jobs?

  • 15 May 2024
  • 8 replies
  • 125 views
msurasky-price
Rank
Userlevel 1
Badge +5

Here is a question for all my fellow IFS Community members. The title kind of says it all but to expand a bit, I’m trying to troubleshoot some code running in the background of IFSAPP10 and, I would like to add some TRACE_SYS.Message lines.

 

Traditionally, I have always been able to see the content of those lines using the Debug Console, but since this code does not run after the UI generates an event (like clicking a button) and rather gets executed in the background, I’m not sure where those TRACE_SYS.Message lines will appear. 

 

Is there a place were I can see the content of any tracing I do an that scenario?

 

Thanks!

icon

Best answer by Tomas Ruderfelt 16 May 2024, 13:57

View original

8 replies

T
Rank
Userlevel 7
Badge +19

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:

 

dsj
Rank
Userlevel 7
Badge +21

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

DSJ - https://dsj23.me
msurasky-price
Rank
Userlevel 1
Badge +5

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?

 

dsj
Rank
Userlevel 7
Badge +21

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;

DSJ - https://dsj23.me
msurasky-price
Rank
Userlevel 1
Badge +5

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.

msurasky-price
Rank
Userlevel 1
Badge +5

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!

T
Rank
Userlevel 7
Badge +19

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.

msurasky-price
Rank
Userlevel 1
Badge +5

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!

Reply


Terms & ConditionsCookie settings