Stefan Cronje · Jan 22

System Process and Session Information in Triggers

Hi all,

I am trying to use some process private variables (percent variables) in Triggers.

I am referring to values from $System.Process, like the ClientIPAddress and CSPSessionID.
These do to not contain values and I suspect it is bacause of scope. I also checked, and the %session variable is not available if the change originated from a CSP request.
I know that in triggers the scope of the variables are to be kept local, that is why NEW is to be used.

Is there a way to access the Process Private Variables in Triggers or get $System.Process to return the correct values?


Product version: IRIS 2022.3
0 128
Discussion (10)1
Log in or sign up to continue

As a first step I would try to find out if your Trigger is running in the same process as your CSP
just writing $JOB  with a  $H into a test global. eg.:

set ^stefan($h,$j)="CSP"  for CSP
set ^stefan($h,$j)="TRIGGER"  for the trigger code
;;; or use
do LOG^%ETN()  ; write to ^ERRORS

For simplicity I am updating the table using the System Management Portal SQL.

I used auditing to get the PID and logged the other in the trigger.
Both are the same value: 95437

The ^ERRORS contains 3472 lines just for this. Do you want to see something specific in it?

There is no reference to %session in it.

In Caché/Ensemble SMP uses straightforward CSP and you have %session object and %request ...
I verified IRIS 2022.2 and 2022.3:
- SMP runs Queries differently and  neither %session nor %request is visible
by variable »  %inBackground = 1 it indicates working in background
and once completed the Job is gone, but SMP is still around

Thank you for clarifying. That makes sense.

It would have been nice to still have that information accessible somehow. If you add audit logs and other things based on triggers, you lose that traceability if SMP is used. This does create a bit of a gap in the audit trail if you are keeping one based on trigger events. The Dynamic SQL audit event can be used, but you can't link it directly to a record that has been updated or deleted, if you are using information that is only available in %session.

Can the InBackground behaviour be changed in a configuration?

I could imagine 2 variants:

  • creating a "clone" of the CSP based "synchronous" Queries we know from C/E to have the unique session
  • just using xDBC based tools such as Squirrel, DBeaver, WinSQL, ..... which is probably better since SMP mimics ODBC mode, but doesn't use real xDBC connection
  • external xDBC provides a 1:1 connection as a terminal session would do.     

Thank you.

The tools used to run updates is not up to me. The end-customer has very strict security policies, so the only way to run SQL is via the SMP. Only that web port is open to most personnel, and then you are doing this on a remote desktop as well.

I understand this. Have experienced it as well.


in SMP IRIS you see this header as in Caché / Ensemble

but click to more  has a surprise in IRIS

Select foreground and you get all %session, .... that you look for.
Recorded with SPOOL , device 2
%application=<OBJECT REFERENCE>[356@%CSP.UI.Portal.Application]
%obj=<OBJECT REFERENCE>[362@%ZEN.Component.html]
%page=<OBJECT REFERENCE>[20@%CSP.UI.Portal.SQL.Home]
%request=<OBJECT REFERENCE>[1@%CSP.Request]
%response=<OBJECT REFERENCE>[2@%CSP.Response]
%session=<OBJECT REFERENCE>[3@%CSP.Session]
%sqlcontext=<OBJECT REFERENCE>[433@%Library.ProcedureContext]
%tStatement=<OBJECT REFERENCE>[369@%SQL.Statement]
<Private variables>

Reverse engineering of the SMP page uncovered this new checkbox to me.
Could be it is documented somewhere


The IRIS 2022.3 documentation has this:

  • Execute Query in the foreground: a check box specifying whether or not to run the query in the foreground. Simple queries run in the foreground are often significantly faster than those run in the background. However, long queries run in the foreground may cause the Management Portal to be unresponsive during query execution. The default is to run all queries in the background.