Two Topics: Verify Workflow Customizing (SWU3), Approach for Orga nization Structure Maintenance

[Dart, Jocelyn]

Hi Dave,
A couple of quick answers:
 
Yes you only need to define a prefix for system/client in which you are
defining your workflow objects.  Transport takes it through to test/
production using the numbers assigned in development.
 
Re development class: A lot of workflow is client independent.  Especially
tasks (TS), workflows (WS), object types, object type programs, etc.
These are essentially development objects just like ABAP programs.  So they
are assigned a development class.  You could use an existing development
class, but I generally like to create a separate development class for
any workflow stuff I am doing.  If you don't normally create development
classes you should probably check with your ABAP group to see what the
standards are at your company for creating them.
 
Re organisational plan: Some others in the group might like to add their
opinions.  It's one of those "how long is a piece of string" type issues.
There are pros and cons either way.  It really depends on your needs for the
workflows you are doing.  If your HR system is separate from your other
system
that becomes more of a problem.
 
It's a good idea to sit down and really think about how you want to work out
your
agent resolution and therefore whether you really need your org plan in your
workflow
system or not.
 
There are two main uses for the org plan.
 
One is to set up the agent assignment to your tasks - i.e. your workflow
security.
You should check what options are available for agent assignment in your
release.
Ways of avoiding/minimising use of the org plan here include creating tasks
as
general tasks (i.e. no security) or in more recent releases you can assign
the
role (i.e. the "activity group") to your task and get out of working with
the
org plan for agent assignment that way.
 
The second use is for standard roles - i.e. agent resolution based on
runtime criteria.
One way to avoid/minimise use of the org plan is to always resolve your
agents as
userids, e.g. create "responsibility roles" and assign them to userids or
make sure any role function modules return only userids.  Another thing that
you can
do is use your role function modules to make remote function calls (RFCs) to
your
HR system to work out the agents, and then convert them to the matching
userids in your
workflow system.
 
Remember as well that EVERY R/3 system has basic org plan functionality
whether or not
you have HR included in that particular system.  So you may want to
transport a minimal
version of your org plan rather than the full thing.
 
I hope that helps a little and doesn't just make the whole thing more
confusing for you
but it isn't a simple issue.  If you are doing a lot of workflow and making
heavy use
of org plan relationships then bringing over the org plan might make a lot
of sense.
If you are doing discrete pieces of workflow that make minimal use of the
org plan some
or any of the above options may be viable alternatives.
 
Suggest you sit down and discuss it with your HR and technology groups, and
with the
business groups asking for the workflows to determine your current and
projected
needs for agent resolution before making a decision.
 
Regards,
        Jocelyn Dart
Consultant (BBP, Ecommerce, Internet Transaction Server, Workflow)
SAP Australia
Email jocelyn.dart at sap.com <mailto:jocelyn.dart at sap.com>
Tel: +61 412 390 267
Fax: +61 2 9935 4880
 
 
 
-----Original Message-----
From: Beverlin, Dave [mailto:Dave.Beverlin at kcc.com]
Sent: Saturday, 24 February 2001 9:06 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Two Topics: Verify Workflow Customizing (SWU3), Approach for
Orga nization Structure Maintenance
 
 
I have some questions in a couple of areas that I'm hoping some of you folks
that are already using SAP Workflow can help me with... we are on release
4.6c.
 
The first is related to the verification of workflow customizing with
transaction SWU3. One customizing step is to define prefix numbers for
standard object types. The help text for that step states that you need to
define a unique prefix for each system and client you have. I'm making the
assumption that you only need to define the prefix for each system and
client where you actually define workflow objects. If I create a single step
task in system A client 100 and transport it to system B client 200, do I
have to have the same prefix number defined in system B client 200 that I
defined for System A client 100? The help text implies that because an
object directory entry is created for each prefix when you create them, that
you don't need to worry about prefixes in subsequent systems in the
transport path. Can anyone confirm that for me? Finally, what is the
significance of the development class that is associated with the prefix? Do
you define a development class specifically for workflow?
 
My last question is related to organization structure maintenance and
transports. Is it more common to maintain the organization structure in
development and transport it to production, or is it more common to maintain
the organization structure directly in production? In the second case, it
would seem that you have to periodically copy the organization structure
from production (using RHMOVE30) to your development system in order to be
able to test the agent assignments in your workflow definition. We have a
'legacy' SAP HR implementation that maintains the organization structure for
a portion of our Corporation in the production HR system. Now we're
implementing other SAP modules (and some corresponding workflow), but
leaving the HR system separate.
 
Thanks for any information you can provide in these areas.
 
Regards,
Dave Beverlin
Kimberly-Clark Corporation
dave.beverlin at kcc.com
865-541-7222
 
 
----------------------------------------------------------------------------
--
This e-mail is intended for the use of the addressee(s) only and may contain
privileged, confidential, or proprietary information that is exempt from
disclosure under law.  If you have received this message in error, please
inform us promptly by reply e-mail, then delete the e-mail and destroy any
printed copy.   Thank you.
 
 ===========================================================================
==