Issues with script actions

[jeremy_gardner]

Howdy,

Question about script actions and domain assignments.   Assume a basic domain structure of global\TOP\Company A.   We have a scheduled job that runs as a user assigned to a Company A domain.   That scheduled job places something on the event queue, which then triggers a script action.   That script action only seems to run if it is assigned to global domain (was originally created in Company A domain).

Is that how it's supposed to be?   Given that script action table is domain-aware out of box, I would think it was intended to be used as such but perhaps not.

Thanks!

Jeremy

[pmorris]

Hi Jeremy,

Can you give me more details about the scheduled job? I have notifications that are "event fired" which then fires off the notification script. The event fires when a field is changed on a form in a different domain (much like your Company A). I am not having any difficulties with it, so not sure what might be happening with your issue.

Also, what release are you using?

Pamela Morris

Teradata

[jeremy_gardner]

Sorry I took so long to reply pmorris.  

We have a big data sync that loads through a standard scheduled job/data import set/transform map.   As data is imported and transformed, we want to run some secondary logic against that new data but found doing so within the transform map created significant delays.   Since the ongoing transform isn't dependent upon that secondary logic, we decided to have the transform map call the event queue, where it can be run in the background and not lock up the transform map.

We then have a Script Action triggered when that event shows up on the queue, which performs the additional processing on that object.

The issue is not with the event queue, it's with the Script Action.   It only runs executes if it's configured in the global domain.   Since Script Actions are only seen by admins, we don't really care which domain they're in, but it's a pain if your admin is working in one domain (eg global\TOP\Company A), create a Script Action, then have to remember to go back and change the domain on that action to global.

Does that help explain what we're doing?

Thanks,

Jeremy

[pmorris]

Yes, that makes sense. I agree with you, it is often cumbersome working with domains and ensuring you are in the correct domain when doing anything, from workflows to forms to scripting. But it does make sense that the particular script you are referring to would need to be at the Global domain since that is where the data load is happening.

[michalewandowsk]

Hi Jeremy,

I noticed such behavior as well. What I discovered was that event triggered via scheduled job runs as user "system". Even if Script Action table is domain aware, in this case event will be processed by this user. As a consequence, only script actions from global domain will be processed. Why? Because user 'system' executes activities in global domain scope.

Correct me if I'm wrong, but this is my conclusion after few hours of investigation.

I think one of the solutions to fix such issue could be impersonation of correct user via GlideImpersonate() class:

var imperson = new GlideImpersonate();
imperson.impersonate(__USER_HERE__);

And last thing - painful development in domain separated instance. That's correct. You can only trust yourself What I mean is that before you click Submit while modifying any domain separated item (like form layout, app menu, Business Rule etc.) you have to think twice and be aware what's your domain (don't believe domain picker, especially if you work on the same instance in several browser tabs) and what's domain of the item being modified.