on 07-13-2008 2:30 AM
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
Hi,
Use this Function Module WAPI_WRITE_DOCUMENT.
Regards,
Surjith
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
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.
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
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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi charan,,
I think the second solution would be a better option
Best of luck,
Bhumika
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
61 | |
9 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.