Clarity

Greetings everyone!

Recently i created a process that contains a Gel Script in which does multiple reads and writes of a custom object, and on our test environment it works perfectly, getting all instanceCode values (sometimes more than 100) and "writing" them with the intented alterations.

The problem i'm having has to do with our production environment, in there the same process/gel script only writes a maximum of 28 instances, of said custom object, i used the folowing on the gel script;

<gel: set asString="true" select="$result/SOAP-ENV:Envelope/SOAP-ENV:Body/XOGOutput/Status/@state" var="XOGOutcome"/>

<core:switch on="${XOGOutcome}">

     <core:case value="SUCESS">

          <gel:log>Record - SUCESS</gel:log>

ANd on the process execution messages (yellow flag) i get for ALL the 100+ records the sucess log.

What is causing this discrepancy between environments? I checked the NSA of both instalations for some clues but didn't see anything that might be the cause of this...

Any clues?

CA Clarity 13.3 version on both.

Thank you!

Tiago

Just a guess!

I would check the Maximum XML Nodes property setting on each server and then check if on the production instance you are exceeding that value.

V/r,

Gene

Hello Gene thank you for your response.

I checked the Maximum XML nodes setting on both environments and it's set to 100 million.

I'm gessing it's not it.

Thank you,

Tiago

I do all my Gel development using a command line processor.  In doing so, I have the ability to increase the logging level on any class used during the Gel script execution.  It also reduces the cycle time of testing as I don't have to upload and then fire off a process to test my script.

How to use <gel:log> for Gel script testing via a command shell

We are executing in the OnDemand environment which make using the sql tablib a little more difficult but I have a datasource snippet that works around that.

If you have access to the production system backend, you could run your script via the command line and increase the log level to see if you are getting any warnings that might lead you to the issue.

I also believe you can increase the logging level via the NSA / CAS (not sure which is the correct label).  I play around with this but I suggest a ticket to support to get help on increasing the logging level.

V/r,

Gene

Did you try storing input/output into XML file on server. SO that you can cross-validate what system tries to XOG into system.

The problem was in some multivalue lookups that the object had, that were writing invalid values to some of the instances so when it tryed to "write" the xog it did not commit.

It's fixed now and working properly.

Thank you!

Tiago