Currency Conversion workstatus error when scheduled from process chain

[Former Member]

Dear,

client is on SAP BPC NW 10 , SP12  .

They have two datamanager packages which execute a script logic, from within the currency conversion is called in both logics.

Both packages are scheduled to run in a process chain, using the ZUJD_TEST_PACKAGE program to execute the packages.

When the package is executed from the scheduled process chain, it gives an invalid error related to work status - but the user executing

the package should be able to change the data.

When the package is scheduled from BPC, it succeeds and data is changed. When the process chain is executed synchronously , the package also succeeds. It seem only to give the work status error when it is launched with a job.

Anyone encountered this issue ?

[Former Member]

First of all, what changes did you make to standard program UJD_TEST_PACKAGE?

Second, take a look at OSS Note 2151113 which says that sometimes user who is executing that program can be mixed up with user listed in in program parameter. Please also check what is the user ID listed in the job and user ID in that particular step.

[Former Member]

Sorry Vadim, but that does not make any sense to me.

First of all , we were able to write data to the 'locked' region with script logic when executing the package from the front end.

Secondly, what do you mean with "locked". Because when configuring a work state, you will specify for the permitted data entry methods for data manager, journals, manual entry, comments and documents. When the "data manager' does not apply to script logic, when is a region then locked for script logic ? Manual entry ?

This is very confusing 🙂

[former_member186338]

Sorry, may be I have concentrated too much on "locked" and not on manager/owner.

About methods:

If we are talking about DM package with the chain to launch script logic - then yes, DM "locked" will prevent any writing by script logic in DM package to the locked region.

By the way, default.lgf script logic executed after data send by input form or journal will be treated as MAN or JRN

Vadim

[former_member186338]

Hi Wouter,

"two datamanager packages which execute a script logic"

Packages executing script logic are unable to write data to the regions locked by work status! No way! The different results you have may be due to different parameters (scope, etc...) for script logic packages launched in different ways.

Please investigate the issue and provide logs and screenshots!

Vadim

[Former Member]

Sure,

but that's the problem. The data region is not locked for the user executing the package. So the user should be able to write data to the data region.

It indeed does write data to the data region when the package is executed through the process chain synchronously. But it does not when the process chain is executed as a job.

[former_member186338]

"The data region is not locked for the user executing the package." locking is NOT for the user! Incorrect idea! Work status lock is locking data independent on user!

[Former Member]

What I mean is , for the work state of the data region, the setting is that the manager can change data through datamanager packages. The user that executes the package is a manager of all the enitites involved.

[former_member186338]

When the script (script logic) is running then it will write data to the target region if this region is NOT locked by work status and will fail if the region is locked. Independent on "user that executes the package"

Vadim

[Former Member]

So what you are saying is the the permitted data entry method for data manager does not apply to script logic ?

But again I have to repeat , the package writes data when it is executed from the front end on this data region.

[former_member186338]

"So what you are saying is the the permitted data entry method for data manager does not apply to script logic ?"

Looks like you are mixing 2 things - access control by security settings per user and work status settings! In order to set work status for some region the user has to be properly configured (as manager/owner). But after work status is set then write result is independent of user performing write!

"But again I have to repeat , the package writes data when it is executed from the front end on this data region." - you have to demonstrate it in details using logs and screenshots!

Vadim

[Former Member]

I don't think I am mixing things. Here are the screenshots :

twice the same package with same selection. One scheduled , the other one fired off synchronously.

Package logs :

[former_member186338]

Unfortunately the screenshots show different data writes (different member combinations) - unable to compare! And scope parameters are not visible!

Second - package script is not shown...

Vadim

[Former Member]

Thanks for your help Vadim,

but we are going to create an OSS message.

I will post the result on this post.

thank you

[damovand]

Hi,

I think we should consider two possibilities why the behavior is different when the package is submitted from BPC DM and when from backend.

For most packages, when submitting from DM there is an option to ignore work status.  Could you confirm if that option is used?  This option may not be available from server side or not set the same way.

The second thing to consider is as one of the other posters said is the user account that is used to run the package. In you screen prints you have BPC_Admin running the package from DM.  I am assuming that BPC_Admin is dialog user, set up to execute BPC from the front end.  Does this same user run the package from the backend?

I think the answer could be either one.  I hope this helps.

Best Regards,

Leila

[former_member186338]

Hi Leila,

The topic author is talking about DM with script logic - and there is NO possibility to ignore work status for script logic!

User is also absolutely not related to work status lock!

Vadim

[damovand]

HI Vadim,

After think a little about this I think user has relevance because if work state allows only owner or manager update the data.  In that case if user who is running the package is in the right role (owner or manager) then update can proceed otherwise it will get rejected.

Regards,

Leila  

[former_member186338]

"I think user has relevance because if work state allows only owner or manager update the data.  In that case if user who is running the package is in the right role (owner or manager) then update can proceed otherwise it will get rejected." - sorry, but absolutely incorrect!

Just to repeat my previous answers: if some region of data is "locked" by work status then nobody can write to this region using script logic.

Vadim

[Former Member]

Hi Wouter,

Are those data been locked via work status?

Maybe your username have access to modify/access data in a locked state.

Check whose username is used in the process chain when running the packages.

Andy

[Former Member]

The user who executes the package has access to update the data - through security and work status settings. When the process chain is executed synchronously it updates the data. The problem is that when the process chain is scheduled through a job it gives the error on workstatus.

[Former Member]

Hi Wouter,

when you run ZUJD_TEST_PACKAGE you specify a user right? what user did you use in the process chain to run the test package.

Andy

[Former Member]

It is a system account, which has been added to BPC security.

[Former Member]

Hi Wouter,

Have a look at note 2077517.

Andy