Development Landscape

[Kisloff, Philip B]

Hi Bill
 
When a new workflow template or standard task is created, it is assigned a
unique internal number identifier. The developer has no influence over this
number assignment and contrasts with the development of ABAPs.
 
What makes the number assignment unique between systems is the prefix number
created during initial customising of that system. Say for DEV the prefix is
901. This prefix is transported into every system the workflows go, so all
workflows in PROD can only have come from DEV if they begin 901.
 
At first blanche, this prefix numbering is robust to deal with two
development environments. Everything created in DEV begins 901, and
everything created in DEV2 begins, say, 902.  In production, before
cut-over, maintained and new workflows will have objects beginning with 901,
and at cut-over will be over-written with workflows beginning with 902. It
is standard that workflows already running will continue to use their
existing objects and only newly started workflows will be effected.
 
Potential Problems
 
1.      DEV will be used to re-create DEV2 at the next roll-out. DEV has no
prefix beginning 902, nor can it as only one prefix is allowed per system.
This means that if the prefix 902 is used again in DEV2, it will start
numbering from 90200001. This means that existing 902 workflow objects will
be over-written in PROD. This scenario is not the original intention of
prefixes, and other workflows sharing a standard task might not use the old
task if the template has not also been transported.
2.      To get around the problems in (1), we could create a different
prefix every time, e.g. 902, 912, 922 etc. We would then have redundant
tasks in Production, after over-writing with 9x2 tasks, but this should not
be a problem.  What is a problem is when we refer to a workflow by it's
unique ID. This is already done in report variants, but can potentially be
done inside workflows and monitor reports. Nothing can be fully tested in
DEV in these circumstances. Also, if a number range is inadvertently used
twice, then I do not think it can be reversed.
 
The answer might be to only create new workflows in DEV, never in DEV2,
although they can be modified in DEV2.
 
Best regards
 
Phil
 
 
-----Original Message-----
From: Van der Burg, Jeroen JA SITI-ITPSEE
[mailto:jeroen.vanderburg at shell.com]
Sent: 07 May 2003 08:50
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Development Landscape
 
 
Hi Bill,
 
There are a couple of serious drawbacks to a multi-development system
approach. One of the main issues is how to synchronise your systems after
changes in your production stream.
 
This can be done either manually (loads of admin overhead and delays for
even small changes on your production stream; and serious consequences if a
typo or mistake is made during the sync effort) or automatically (with
transports, which obviously has a high potential for overwriting any release
stream developments).
 
>From personal experience I would never decide for such a landscape setup due
to the overhead costs, administrative delays and risks with your next go
live that will be the result. That is not to say that you will not
experience any problems when trying to implement major developments in a
one-stream environment, but at least these problems will not result in a
major waste of resources as they are focussed on the end goal (getting stuff
correctly implemented into your production environment) and not on non-value
adding overhead like transport procedures, regression testing and transport
management teams which will only increase the cost base of your project
team.
 
In a one-stream environment with major developments underway Workflow is the
least of your worries as, due to the versioning and triggering
functionality, it is not difficult to prepare a major new workflow
development, test it extensively and only have it replace the existing
functionality on production after you are completly happy with it; while
still being able to maintain the existing workflow during development of the
new functionality. The abap developers do not have those options and have to
be intelligent (or try to convince their customer that, yes, he really
really really needs an extra development stream to reach the deadline for
release 2 blahblahblah).
 
I am unclear what you mean with 'duplicate workflow numbers', when new
versions are transported to your production environment they will just
become new active versions of the workflow task definition.
 
 
Hope this helps,
 
 
Jeroen
 
 
 
-----Original Message-----
From: Craig, William [mailto:william.craig at gwl.com]
Sent: 06 May 2003 17:36
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Development Landscape
 
 
All,
I have a general question about development and how other companies have set
up their SAP landscape.  Our company just went live with SAP and they have
proposed a new landscape because we are going to have a phase 2 go live with
some more functionality.  What they have proposed is to have a DEV, QAS, and
PROD layout for all existing ABAP and workflows, then they want to create
DEV2 and QAS2 by making a copy of DEV and QAS where they will be doing
development work for the next phase.  When they are ready for phase two they
will overlay DEV and QAS with DEV2 and QAS2.  They have proposed this
because they are modifying some ABAP code that they are currently using, but
it would be incompatible with the current production environment.  The
problem that we see is that for workflow, any modifications or fixes would
need to be done in both places, but more importantly if we develop a new
workflow that needs to go into PROD prior to the Phase 2, and we create new
workflows for Phase 2 we will have duplicate workflow numbers when Phase 2
goes into effect.
 
I am guessing we are not the only company in this situation and I would like
to hear how other companies have done this.  Perhaps this approach of two
DEV and QAS boxes is not a good idea?  If you have any comments or
suggestions we would appreciate it.
 
Thanks,
 
Bill Craig
SAP - Workflow Team
Great-West Life & Annuity
Desk Phone - (303) 737-4053
Email - william.craig at gwl.com