Clarity

It appears that when the gel_objectInstanceId or processInstanceId variable is passed in steps other than the start step it can cause unexpected results.

After upgrading to 13.3 we had a number of process failures and support has recommend that we pull out gel_objectInstanceId from all of our scripts and in the start_step we persist gel_objectInstanceId into another variable.

<gel:persist scope="INSTANCE" value="${gel_objectInstanceId}" var="thisInstanceId"/> 

The also recommend that you do not place any gel in the start step except for the setting the persistent var.

Reference Tech Document TEC495262.

Would have been good to know before developing 100+ scripts!

Umm.... wow.

When did this come about? Why is this not a bug?

This would have a huge impact for us and would be an upgrade show stopper.

The tech note was dated 2/12/2013 so I think it has been known for a while.

All of the processes that have been failing on 13.3 worked on 13.2.

I also ask our CA consultant why this isn't a bug.  Still waiting for an answer.

Another thing is that this doesn't really make since the gelContext is inherited in each step a step should be looking at the same  gel_objectInstanceId.  Also I believe gel:log use gel_objectInstanceId to determine where to log the messages.  The other thing for this to happen while in a step, means that some other process/step is mucking up gel_objectInstanceId which is why they recommend capturing it in the start_step along with no other gel script.

V/r,

Gene

This is a known issue and we have all our gel scripts secured by declaring those 2 variables (persisting) a second time back when we were on 12.1.1. Also, mind that you cannot use the INSTANCE variable declared in the same step cannot be used in the same step ( I have not tested this, it may work inconsistently). In fact, it appears gel scripts are not thread safe in 13.3 -  do some testing on this . I have found it work inconsistently when the same process triggered off multiple updates on a list view or Gantt view task updates. Waiting to hear back from CA support.

Regards,

AK

>>you cannot use the INSTANCE variable declared in the same step cannot be used in the same step ( I have not tested this, it may work inconsistently).

I have tested this in 14.4 and this is consistent behavior.  however, if you use PROCESS or GLOBAL, you can see the variable value in the same step.  this is the inconsistency which i find puzzling?  do you have any insight into this?

Great, I'm in the process of evaluating all our scripts to see which need to be updated before upgrading to 13.3, yet another thing to have to look for. Thanks for posting this!

I know the pain.  We are reworking all of our scripts into a common set of practices / scriptlets:

Include files for common scriptlets (login / logout / invoke)

Common set of variable prefixes / names for includes / steps.

Wrapping scripts in <core:catch>  with <gel:log> to see the exception.

Using <core:break> with a dummy <core:forEach> for cleanly exiting a gel script

Using ConfigurationManager for obtaining properties

Removing all <sql:Update> tags.

Wrapping all sql text with  <![CDATA[    ]]> tag.

Things I am still trying to figure out.

Xog password changes – We have are requirement to change a password every 60 days.  I am looking for a simple way to have this updated in all the scripts and not have it in clear text in an include file.  I have figured a way using com.niku.union.security.DefaultSecurityIdentifier but not sure it is the way to go.

 

WriteCustomObjectInstance – We have quite a few and we are removing <sql:update>.  My thought is to pass a sql results set into to a write loop include file and use column names for the ColumnValue name attribute.  This would really reduce the gel script verbiage.

V/r,

Gene

Yup, I'm in the same point, and trying to learn GEL/XOG all at the same time. I'm going through almost the exact same exercises.

Using <core:break> with a dummy <core:forEach> for cleanly exiting a gel script

I've seen this mentioned a couple of times, and I believe the example you posted in another thread made use of it. Is this to essentially emulate an "exit" type command?

Using ConfigurationManager for obtaining properties

Again, seen this one a few times. Is there any documentation out there on what is available and how to properly use it?

Xog password changes – We have are requirement to change a password every 60 days.  I am looking for a simple way to have this updated in all the scripts and not have it in clear text in an include file.  I have figured a way using com.niku.union.security.DefaultSecurityIdentifier but not sure it is the way to go.

Luckily we don't have to change our passwords nearly that often, but this is something I've been thinking about as well. I've seen several posts on the forums about it but none that has any sort of formal resolution.

WriteCustomObjectInstance – We have quite a few and we are removing <sql:update>.  My thought is to pass a sql results set into to a write loop include file and use column names for the ColumnValue name attribute.  This would really reduce the gel script verbiage.

Heh, I just posted a similar question