cancel
Showing results for 
Search instead for 
Did you mean: 

Step for User Decision

Former Member
0 Kudos

Hi All,

I have a scenario and two solutions for it.

Please give me the input for which is a better solution and why.

Scenario - Approver have to either Approve/ Reject a particular request made.

The user decision has to come from Java front end and the workitem created has to be executed externally

( not by opening sap inbox)

Soln 1 : Create an asynchronous task and custom terminating events for the workitem and trigger terminating event for any user decision Approve or Reject.

Soln 2 : Send an normal decision task and programatically execute one of the decision using the WAPI* FM when user clicks Approve/Reject.

Both of them I think uses the WAPI * FM.

Thanks

Chandran

Accepted Solutions (0)

Answers (3)

Answers (3)

surjith_kumar
Active Contributor
0 Kudos

Hi,

Use this Function Module WAPI_WRITE_DOCUMENT.

Regards,

Surjith

Former Member
0 Kudos

Hi All,

Thnaks for the replies. I know the second solution is better.

Any particular reason for choosig any particular solution????????

Thanks.

pokrakam
Active Contributor
0 Kudos

I think one question mark is enough to indicate a question.

Like you, I have not understood any of the reasons given for the second solution. I certainly don't know where WAPI_WRITE_DOCUMENT fits in, it doesn't even exist. It would be nice if people would post answers they actually know about.

I also think the first solution is better because it's easier to implement and easier to manage errors using standard WF admin tools rather than having to code for it.

Cheers,

Mike

imthiaz_ahmed
Active Contributor
0 Kudos

First of all, I don't agree to using a user-decision step here. There are several ways especially when you are integrating a third party tool or application. Create your own RFC's.

Regards, IA

Former Member
0 Kudos

Thanks Mike about your comments on question mark (Hope they are not in the Rules of Engagement)

The first solution requires a BO object to passed on to the workitem and the system creates a link the terminating event and the specific Workitem ID.

This makes the system keep listening to temrinating events all the time because of this linkage.

For example there are 100 workitems based on a diffrent terminating events, then think about the wokload on the system performance.

Do you still think the first solution is better?

As you said people who have no clue about answers give answers.

Thanks,

Chandran

Former Member
0 Kudos

Hi ,

Thanks for your reply.

I agree RFC is one solution. But what about the situation where we need a workflow and the steps in workflow is dependant on the user action through RFC.

Any other suggestion if we dont use a user decision step...

Thanks

Chandran

pokrakam
Active Contributor
0 Kudos

Hi Charan,

Yes it is in the rules, that was just a friendly reminder - with my moderator hat on it would have been in red Some folks used to post like that all the time and it annoyed a lot of people, but it's not so bad nowadays.

"Listening" is more of a virtual concept we use because it's easier to explain, the system doesn't really 'keep a connection open' or anything like that. There's neglegible resource impact, all it means is that it keeps an entry in the instance linkage table which is optimized for far greater volumes than any amount of decisions you're likely to have.

Cheers,

Mike

Former Member
0 Kudos

Thanks for a detail reply.

Exactly the type of answer I was looking for regarding the resource usage.

I dont know about this ;-).

Regarding using an asynchronous task.

Is it ok to use it for a user decision even where there is no absolute database update and the terminating events is just a way to get user input from the frontend.

pokrakam
Active Contributor
0 Kudos

No, unfortunately you cannot use terminating events with decision tasks (and I have no idea why - it just seems to have been hardcoded into the system like that).

You will need your own custom object, but it doesn't need to do anything so any dummy method will do. You just use it as a placeholder so that your trerminating events determine which branch to continue on.

Reading IA's comment, this brings up another point: A regular user decision step already has it's own Java-based iview in the portal. But I assume you already know that and need something different.

Cheers,

Mike

Former Member
0 Kudos

Sorry I was not clear in my question before.

I still refered to the first solution which uses a Aysn Task and a method which does not have any code (just a placeholder)

IA is absolutely right but I dont have the flexibilty to use an ivew.

Thanks a lot for your reply. I would close up this thread.

Just some additional clarification if you can bring up

What additional code that would be required for the second solution (both uses a sap WAPI FM )

Both can be tracked by WF tools by finding out the agent and the person who have completed the Workitem so which tools you were mentioning about

Actually I did not get which is a better solution but realized both can be used atleast no worry on the performance load. My be this topic can go for a long time to figure out

Regards,

Chandran.

imthiaz_ahmed
Active Contributor
0 Kudos

When you say, the approval is done externally, then in that case you are somewhere starting the Java application for approval expecting a result, at that point Java application can make use of any custom RFC and send back the decision took by the approver.

Regards, IA

pokrakam
Active Contributor
0 Kudos

I know that not many people actually do it, but I thought I made it pretty clear when I said "error handling". There's not much that can go wrong on the calling side when raising an event, apart from the target system not being available. If you are manipulating a work item however, there are other things that can go wrong.

Standard tools: work item error monitoring, event queue administration etc.

The first solution provides better separation into components, whereas the other is more closely integrated. On the other hand you also lose the ability to process your decisions using the first. The choice in the end is yours.

Cheers,

Mike

Former Member
0 Kudos

Second Solution is Always Preferrable just because it is simple with the use of the WAPI SAP_WAPI_DECISION_COMPLETE. the First solution is complicated.

Before Using the Above WAPI, use the Below FM to list the WorkItems corresponding to the Business Object.

SWI_WORKITEMS_OF_OBJECT_GET

Former Member
0 Kudos

Hi charan,,

I think the second solution would be a better option

Best of luck,

Bhumika

devrajsinghr
Active Participant
0 Kudos

What the reason for choosing 2nd one?

regards Dev..