Use of BADI_UJW_WS_CHANGE to change work status from script logic

[Former Member]

Hi Experts,

I am aware of the post which uses implementation of custom logic to change work status from script logic by using the start badi command. I am interested to know if anyone has been able to achieve the same functionality utilizing standard BADIs, like BADI_UJW_WS_CHANGE  and if an example of its use can be provided.

Also, I have read about UJW_LOCKOUT_SCHEDULE_BADI. Is this BADI also designed to change a particular data region work status from let's say status "started" to "submitted"?

I am trying to get the best approach for implementing systematic logic for changing work status either using the custom logic or standard BADIs.

Cesar.

[Former Member]

Raghu - as Vadim is pointing out, the post How To: Change Work Status from Script Logic using BAdI works fine. We are using this sample code to achieve our objective. There is an important thing though that needs to be considered. The use of QUERY = ON seems to be less efficient than getting the application data in the BADI itself using the method run_rsdri_query. Please refer to , which expains this improvement in performance. You can decide which option works better for you depending on the volume of data you need your BADI to change work status to.

[former_member186338]

Hi Cesar,

But what is the reason to run this badi with QUERY = ON? You don't read transaction data - just work status manipulation...

And the sample in the provided link is correct:

QUERY = OFF

WRITE = OFF

Vadim

[Former Member]

Thanks Cesar for the information

[Former Member]

Hi Vadim, in our case, we have the particular requirement of analyzing huge data regions to determine if we need to change the work status or not. Instead of passing the data region as *START_BADI parameters within a *FOR loop, we require to get the application transactional data within the BADI, evaluate some logic and if conditions are met, we change the work status. This is why we are using this approach.

[former_member186338]

Well, *FOR loop is the only strange thing in the original document Loop can be easily performed inside badi.

But the requirement to analyze transaction data before changing status - it's an absolutely different thing. And I don't clearly understand the business logic!

Vadim

[Former Member]

We are using BPC for something I think nobody else in the World is using it for. If our project is successfull, I will write an article about it. Stay tuned, I will let know you if it becomes a success.

[Former Member]

Hi Cesar,

We also have same requirement, i would like to know if you have already started using the BADI BADI_UJW_WS_CHANGE

Best Regards

Raghu

[former_member186338]

Hi Raghu,

I have already answered you how to change work status using custom logic badi launched by script logic DM package. BADI_UJW_WS_CHANGE is for different thing!

Please read once again

Vadim

[Former Member]

Hi Vadim,

I have already gone through the above link which you shared on custom BADI.

I thought BADI_UJW_WS_CHANGE is specific to work status change.

Thanks for the clarification.

I thoug

[Former Member]

Hi Cesar,

BADI UJW_LOCKOUT_SCHEDULE_BADI doesn't change WS. It works instead of WS check. There is a sample implementation that's delivered with it.

For example, in the case described in the blog, author would be able to implement following logic. Connect somehow Entities that should be locked together, for example in MD.Ask user to lock just one Entity. Then when comes check for any entity BADI would check if the main Entity is locked and returns status correspondingly for all connected Entities. This makes WS table smaller and WS check runs faster.

Regards,

Gersh