Anda di halaman 1dari 12


Consultant Name Best Practice (#1, 2 or 3)

Robert Courson 2

Charlie Der 3

Eric Kaspriskie 3

Mike Kirkwood 3

Greg Louallen 3

Jill Mayo
Bill O'Brien 3

Kamala Rao 3
Bob Sampson 1

Jens Schmeer 3

Kai Schub 3

Ian Story 3
Daniel Wilhelmi

Brooke Williams 3
Dave Willingham 2

Best Practice:
1) Process Chains (Metachains)
2) Intelligent scheduling software like Redwood
3) A combination of 1 and 2
Batch Job Scheduling Best Practices


Intelligent scheduling software like Redwood

A combination of 1 and 2

A combination of 1 and 2

A combination of 1 and 2

A combination of 1 and 2

A combination of 1 and 2

A combination of 1 and 2
Process Chains (Metachains)

A combination of 1 and 2

A combination of 1 and 2

A combination of 1 and 2
A combination of 1 and 2
Intelligent scheduling software like Redwood
tch Job Scheduling Best Practices

Process chains for DP is best and for SNP, process chains certainly can work, but
could be overkill, although we did use them at ACH.
I agree with Brooke – process chains are great within a single system but when there
are job dependencies across systems, then a central job scheduler is very helpful.

The majority of my experience has been to use metachains with a third party scheduler.

Option 3 is the most flexible. My present customer has many ECC jobs that have to
coordinate with planning in APO. While you could toss the ball between systems with
standard SAP, job scheduling in a 3rd party tool gives you a better way to manage
failures in a cross-system environment.
I am not sure if it is best practice, but what I have experienced at most customers is #3,
a combination of the 2. We usually have “modular process chains” and batch jobs
scheduled by Redwood or something like it.
If I recall correctly, at one of my previous customers, we did kick off the jobs in ECC
after the process chain in APO completed (or maybe it was APO kicking off
BW…..but definitely across 2 landscapes).
Another vote option 3 as the most universal or versatile solution.
I believe a good combination of the two is the best option.
1. You can have process chains in SAP environments (APO and BW)
2. You can have processes in other environments (Legacy)
3. The two may need to interact or may be interdependent
4. To orchestrate the synchronization, many customers use a scheduling tool and this
setup works well.
It makes for better scheduling and controlling the batch process.
Process Chains have multiple steps/ jobs that execute in a sequence. In the scheduling
tool that entire process chain is one job. If you were to schedule the individual steps/
jobs, there would be too many to manage and keep track and sequencing becomes a
My vote would be process chains. The advantages to me are:

1. Native to SAP (= “free”)

2. Can enable cross environment processing/jobs
3. Has most of the “basic” intelligence needed
4. Doesn’t require an additional skill set/resource/knowledge from another software

I don’t necessarily have a problem with the intelligent software, but I think there is
always more of an additional admin burden, can add significant delay as well to make
“simple” changes.

If we are talking pure SAP landscape, I would say that using Process Chains is
probably the route.

As soon as we have to integrated between SAP systems and non-SAP systems, option
3 – both.

Metachains operating a number of local process chains under them seem to be the best
practice (in coordination with || processing profiles at the local chain level). Now
executing the metachains with a 3rd party scheduler like Redwood is quite common,
although I don’t know if it can be considered a best practice over executing them with
I’ve used the “Remote Process Chain” process type in RSPC to trigger local chains
across source/target systems (from ECC>APO, APO>ECC, BW>APO, and
APO>BW). It’s fairly easy to connect and schedule them all.
I’d vote for ‘Combination of the two’, especially when non-SAP systems are involved.
The process chain manages the process within the SAP environment, but often the
customer will have other dependent jobs running in non-SAP systems. Using a
central job scheduler will help manage the overall process, not just the process within
the SAP landscape. Furthermore, having a central job scheduling software simplifies
the IT support required to manage and monitor batch jobs across the organization.
Promotion of Process Chains through the Landscape

So far I have only been promoting from DEV to QA to

PROD. This happens (process chains getting messed up)
also when you transport variants with SIM versions
I’ve done both … promote and create in PROD. I prefer
promoting from DEV. It seems to fit with the whole 3
system philosophy (DEV/QA/PROD). You have to attach
the subchains to the main chains in the transports yourself.
It’s not automatic. Yes, I have seen the chains get
“messed up”. It’s usually caused by the variants not being
transported with the chain. If the variant doesn’t exist in
the target, you’ll get a weird, system generated number in
its place.

I’ve done both (in emergencies) but try to stick with the
promoting (and advise the customer that this is the best
way to do).
I also did both. In rare emergency situations when a fix
was needed right away and we could not wait for the
transport, I did changes directly in the system (QA or
Prod). Right away after and normally, though, I did the
changes in DEV and transported it again through so all
systems would be in sync. Building on what Daniel said,
if there are configuration elements that are not transported
yet or can’t be transported, then those need to be created in
the target system (QA and PROD) manually prior to the
PC transport. As long as then all variants have the same
names, I typically had no problems with corruptions.

So far I have only been promoting from DEV to QA to

PROD. Just as FYI that as of SCM 7.0 EhP2 calling
transaction RSPC routes you automatically into RSA
section Process Chains.
I haven’t read all the replies, but I always create P-chain
transports (mostly in RSPC, but sometimes in RSA1) with
generic variants and promote them up to Q and P
environments. Then I’ll tweak the variants in each
individual environment because the
selections/users/versions may have changed (D never has
much data or many users on it). I would also recommend
– unless you have hundreds of process chains – to bundle
up all your p-chains into a single transport at the very end
(after all your baseline config has moved up). When I’ve
seen corruption in p-chains, it’s usually been around alert
macros batch jobs: The alert types were created in in DEV
but never transported up. And the alert macros/jobs are
referencing these alert types which aren’t in the target
Yes, often times we created variants in the target system
first, and only then promote the PC across. But as pointed
out before, I’ve seen (and am seeing now) a mixture of
transport vs. creating on the fly. The more complicated one
we are attempting to transport, but simples things like
triggering a CIF queue open or Close job we’ve
configured in the respective target system only.