Scheduler not running transaction correctly

[Former Member]

Hi,

I have a problem using the scheduler.

I have created a transaction whereby i am using an RFC_TABLE_READ to return data, in this i have a property xml property defined for passing in fields to the RFC_TABLE_READ fields request this is static in the transaction. This works without error running the transaction manually in BLS and completes fine.

If i run this from the scheduler it throws an error "AssignXml: cannont assign from empty source" this is because it is not applying the fields attribute and as a reult the transaction fails. The source is not empty.

Has anyone seen this before ?

version 11.5

Regards,

Emmett

[Former Member · Accepted solution]

Emmett O'Connor,

Are you passing server user name & password etc exclusively in the link configuration of JCo call action?

Regards,

SB

[Former Member · Accepted solution]

Hi SB,

No the SAP server has been configured as an alias and this is being referenced in the link configuration. It definetly seems to be stopping when it comes to the assigment of my fields parameter to the JCO Function call - but this isnt a problem when run manually only when run via the MII scheduler.

One thing whn i evaluate my xml Fields parameter in BLS it shows as blank - even though it isnt, is this normal for an xml variable ?

Thanks,

Emmett

[Former Member · Accepted solution]

Emmett O'Connor,

Hope you are entering correct inputs properties in the job scheduling dialog box.. There could not be any other reason..

Regards,

SB

[Former Member · Accepted solution]

Hi SB,

This is the case only parameter i am passing across is a material number which is fine as i can see the returned inspection lots being written to a file. The query fails when it gets to assigning the fields variable to the JCO Function. This is defined in the query statically and does not change, it is an xml property as follows

<?xml version="1.0" encoding="UTF-8"?><FIELDS>

<item>

<FIELDNAME>VAEDATUM</FIELDNAME>

<OFFSET/>

<LENGTH/>

<TYPE/>

<FIELDTEXT/>

</item>

<item>

<FIELDNAME>VEZEITAEN</FIELDNAME>

<OFFSET/>

<LENGTH/>

<TYPE/>

<FIELDTEXT/>

</item>

</FIELDS>

and i am using the "assign xml" property to add it to the JCO_Function Fields input parameter. Cant figure out how it is failing.

Emmett

[agentry_src · Accepted solution]

Emmitt,

I am not sure I understand your statement that:

"This is defined in the query statically and does not change, it is an xml property as follows"

What Query are you referring to?

Regards,

Mik

[Former Member · Accepted solution]

Hi Michael,

Apologies, what i should have said is this id defined in the BLS transaction as a property and does not change, i.e. it is a statc property i am not assigning anything to it.

Emmett

[Former Member · Accepted solution]

Emmett, I suspect that the way scheduler passes parameters forces you to put a value in the scheduler configuration for each transaction input (e.g. if you don't put anything in there, a blank value will be assigned to the input parameter, rather than leaving it untouched).

Just a thought...

Rick

[Former Member]

Emmett O'Connor,

That was precisely my guess/question earlier. Though you have set properties within the transaction, while calling it in a scheduler, have you tried re-entering same values?

BR,

SB.

[Former Member]

Gents,

This solved the problem and i am not passing the xml string to the paramaters - the way the Transaction is built there is only one parameter that actually needs to change (material number) to return different sets of results that is why i did not pass to other "static" parameters.

This is slightly off putting that i am "forced" to assign a value to any parameter used in the transaction when called via the scheduler.... if i where to create these "static" parameters as outputs instead of input parameters would i still need to do this ?

Thank you for your help, much appreciated.

Emmett

[Former Member]

Hi,

A second thought..

If the variables are static and you are not going to change them , better create them as local variables.

Regards

Kishore