Universal Worklist - TS20000166 (purchase order release) and SWFVISU

[Kjetil Kilhavn]

 Tirsdag 31. mai 2011 12.06.38 skrev Mike Pokraka :
> Hi Kjetil,
> 
> The standard solution is specifically designed around GUI. By applying the
> same ME54N auths as you give your users to a decision task, you are
> replicating the same level of security. By adding workflow routing and
> taking away ME54N you are enhancing security.
I have to disagree, possibly because I don't understand your solution design. 
How can I enhance the security by taking away ME54N, or in my case ME29N/ME28?

A custom decision task would have to replicate a lot of the standard task 
functionality to handle significant changes, rejections and of course 
approvals. That is unnecessary duplication of work in my opinion - but of 
course the customer will get it if they require it.

If the users themselves don't have ME29N authorization and the authorization 
for the release codes they are authorized to handle, I would have to use a 
system user for the actual release. That's where I see a big problem in 
improving security which you claim is possible. Forwarded work items could be 
executed by unauthorized users unless I implemented exactly the same 
authorization checks that SAP already implements in ME29N.


> I've often said that workflow can enhance or blow away security, 
> depending on good design or lack thereof.
The previously implemented solution blew all security away. Any user getting 
his/her hands on a work item could release any purchase order - the user's 
authorization to release was not checked, nor the amount limits.

The new solution identifies the release agent depending on the release code. 
For some codes the customizing is used, for others organization hierarchy 
climbing is necessary - and in those cases I check the identified user's 
authorization for the release code in order to find the correct release agent. 
It would of course be possible to give the users authorization to the release 
codes without giving them authorization to ME29N, but I fail to see the point 
of this. Some users will use the UWL to release purchase orders, some will use 
ME29N or ME28 directly because they don't have UWL available, and some will be 
using both methods.

The standard task now has possible agents defined, and the properties have 
been set to prevent forwarding to others than the possible agents. I've also 
classified the task and created a possibility to define substitutes for 
purchase approvals. All of this would also have to be done to a user decision 
task, and with a user decision task I would have to have subsequent tasks 
checking the work item (executing) agent's authorization and then either call 
a function module with RFC destination to release the purchase order with 
another user ID, or perform the release in a background task - adding the 
complexity of handling various error situations that could occur in that 
background task too.


> Whilst I agree with you in sticking close to SAP standard in most cases is
> a good thing, IMHO the SAP Standard for many +workflow+ scenarios is
> little more than a "Quick and dirty" to get folks up and running with
> minimal fuss. ESS is a prime example - you dont't even need UWL or SBWP
> for the simplest setup. Purchasing workflows are a bit dated to say the
> least, and there's nothing wrong with a well thought out solution that
> fulfils business requirements.
I agree. The problem is in creating a "well thought out solution" :-)
The previous solution was certainly not well thought out. It didn't have 
authorization checking or possible agent specification, and didn't handle 
rejections properly. The approver could choose to reject, but the purchase 
order was not updated with the new status and this meant in most cases no new 
workflow would be started automatically since the purchaser could not cancel 
the rejection after e.g. changing the account assignment.

It may be true that the purchasing workflows are a bit dated, but they work 
pretty well I think. The purchasers are notified about approved and rejected 
purchase orders too, which I initially thought they wouldn't want - but they 
like it because then they don't have to keep track of this manually.

> Just my 2p,
Your 2p are always appreciated - and usually I don't disagree :-)

> Mike
> 
> On Fri, May 27, 2011 1:45 am, Kjetil Kilhavn wrote:
> >  Tirsdag 24. mai 2011 17.48.24 skrev Griffiths, Mark :
> >> I would copy and change the workflow to use a user decision and then use
> >> a
> >> UWL view to process the approvals.  The workflow could then release the
> >> PO
> >> using a BAPI in a background task.
> > 
> > That is precisely what I *don't* want to do. I want the solution to stay
> > as
> > close to SAP standard as possible. Less maintenance, hopefully. At least
> > it
> > will be done that way initially. In my opinion people are dismissing
> > standard
> > far too quick, and only later realize the maintenance cost.
> > Since the company who first implemented a solution did such a poor job it
> > is
> > easier to persuade them to try SAP standard so they get proper
> > authorization
> > checking etc.
> > 
> > ObFrust: The other day I had to check (EhP 4 post-upgrade check/fix) a
> > report
> > which was a copy of SAP standard report. And for what? To remove one
> > field from the standard output setup, add another field to the standard
> > output setup
> > ... and finally to add a new field to the available output fields and to
> > the
> > standard output setup. Using implicit enhancement points everything
> > except for
> > one statement could be implemented. This statement had to be "replaced"
> > in a
> > modification to read configuration for standard transaction codes when
> > the special transaction codes are used, and of course execute as normal
> > when the
> > ordinary transaction codes are used.
> > 
> >> Regards,
> >> 
> >> Mark
> >> 
> >> -----Original Message-----
> >> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> >> Of
> >> Dart, Jocelyn Sent: 20 May 2011 05:55
> >> To: SAP Workflow Users' Group
> >> Subject: RE: Universal Worklist - TS20000166 (purchase order release)
> >> and
> >> SWFVISU
> >> 
> >> Hi Kjetil,
> >> So you've taken away a user decision task or WebDynpro app?
> >> And replaced it with a SAPGUI task...
> >> 
> >> SWFVISU is a possibility.
> >> You could also use the UWL XML config and use the function module
> >> launcher
> >> to call the relevant BAPI to release the PO. You might need to create a
> >> wrapper function module to simplify it a bit... but that approach works
> >> ok. You could even allow mass approval with the checkbox options (check
> >> out the standard WorkItemApprovals view).
> >> 
> >> Regards,
> >> Jocelyn
> >> 
> >> 
> >> -----Original Message-----
> >> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> >> Of
> >> Kjetil Kilhavn Sent: Thursday, 19 May 2011 12:39 AM
> >> To: sap-wug at mit.edu
> >> Subject: Universal Worklist - TS20000166 (purchase order release) and
> >> SWFVISU
> >> 
> >> I have a request to give the users back the button they say I have
> >> removed.
> >> I haven't really removed anything, just switched from a custom workflow
> >> full of security problems to the SAP standard workflow which doesn't
> >> circumvent authorizations....
> >> 
> >> Anyway, the users would like to be able to approve (possibly also
> >> reject,
> >> but that's less important to them I believe) the purchase orders
> >> directly
> >> from the work item display in Universal Worklist. Now, there is the
> >> wonderful world of SWFVISU, but is there a SAP standard application
> >> which
> >> can be used for this purpose. Currently they see the task description, I
> >> think they still want to see that.
> >> 
> >> Any low-hanging fruits, or do I have to tell them it will take 42 days?
> > 
> > --
> > Kjetil Kilhavn (+47 40220607)
> > Blue Consulting AS (http://www.bluec.no)
-- 
Kjetil Kilhavn (+47 40220607)
Blue Consulting AS (http://www.bluec.no)