SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 1
SAP AMERICA
May 15, 2003
10:00 a.m. CDT
Coordinator
Ladies and gentlemen, thank you for standing by and welcome to the BW
Know How Teleconference. At this time, all participants are in a listenonly mode. Later we will conduct a question and answer session with
instructions given at that time. As a reminder, this teleconference is being
recorded. I would now like to turn the conference over to Mr. Oliver
Mayer, from the BW Rig. Please go ahead, sir.
O. Mayer
Okay, thank you, Bill. This is Oliver Mayer, and first of all, I’d like to
thank everybody for dialing in today’s call and taking the time out of their
busy schedule to listen to this presentation and, of course, I’d like to thank
Rudolf Hennecke, my colleague out of the EMEA Rig out of Germany for
taking the time to put this presentation together and to take the time of his
day, towards the end of his work day to present this.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 2
So without further ado, I would like to turn the call over to Rudolf and the
topic, “Modeling Aspects in Process Chains.”
R. Hennecke
So, hello, everybody, to this conference call on modeling aspects and
process chain. Yes, first of all, I hope that everybody could download the
presentation. So for the next 30 to 40 minutes I will give some overview
on how to model process chains and then we will have some time for
questions for about 20 to 30 minutes.
So let’s come to page one, which shows you the agenda of today’s
conference call. You will see that the conference call is divided in four
blocks: a short, very short introduction and then several modeling aspects
on process chains, first conceptual and project-related issues; then from
processes to process chains (means collecting processes and then building
process chains out of it) and then some general modeling principles.
So let’s start with the introduction. We are now on page three. You’ll
find the page number in the upper-right corner of each slide. As you see,
process chains are built for administrating and automating the BW
administration and this means not only the data-load processes, which we
could automate already in BW 2.0 (using info package groups) but also all
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 3
other administration processes that might run after or even before loading
data (like database statistics update or rolling up of aggregates).
It means process chains are the central point of administrating for all
processes that need to run in BW before data can be made available for
end users. So therefore, on page four you find another definition on the
term “process” because in this presentation I will use the term process
sometimes, and therefore I will precise the definition of what a process in
a process chain is.
A process is composed, as you can see, out of a process type and a variant,
and the process type describes what administration task has to be
undertaken; for example, the data load or roll-up aggregate.
In the variant, it’s a configuration of that process at the time of definition,
means it is the for example the info package to be loaded. Or it is the info
cube for which the roll-up of aggregates has to be done. Therefore,
process is equal process type plus variant.
You can see from this presentation that I will not talk in detail about the
tool. This information can be found in last year’s conference call on
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 4
operating BW 3.0 using process chains. In this conference call from 2002
you’ll find information on the tool itself and how to use it.
Today’s conference call is more on how do I set up process chains? How
do I model process chains?
We are now on page six. Within the conceptual and project-related issues,
two points are very important. The first thing is that you have to think of
when do I start to implement process chains? This, I recommend to do it
quite early in the implementation phase of the project, means right after
having implemented your data flows. Means do not start implementing
process chains five days before going live with your project.
Then, after having implemented your process chains, use the final
preparation phase of your project to test your process chains on
performance, correctness and robustness. You will see, as there a lot of
modeling on process chains, you really need to start with it early in your
project.
Next point is on project team and know-how and what I want to tell you is
that the project team members that work with process chain do not only
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 5
need to know about the tool, but also on data warehouse administration
(basic tasks to be undertaken with administrating a huge data warehouse)
and also the need to have knowledge on the single process types they start
and schedule in process chains. Means they need to know what the system
is doing when data is loaded or when aggregates are rolled up.
The other thing is that usually it’s very good to have central project teams
implementing these process chains. If this is not the case or if you need to
work in parallel and decentrally, then make sure that the different project
teams implementing process chains share their knowledge and that they
also document what they schedule at which time.
Now on slide seven I give you prerequisites before starting implementing
a scenario with process chains.
First question, what is the frequency of this administration scenario to be
performed? Is it something you do once or is really something you have
to do periodically?
Means for example, you should evaluate whether it makes sense to
implement the initialization of data-loading scenario within the process
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 6
chain or whether this is an ad hoc processing, which not needs to be
automated using process chains because it is just executed once.
The next thing is data quality. Is the quality of data good enough that,
periodically, subsequent processing can be started? Means if data quality
is very bad, usually then you have to work on correctness of data by
repairing it (p.eg. by contacting source system people).
If this is the case for your data-load scenario, then you should first try to
stabilize data quality before implementing this with process chains.
Last point: Is the availability of data foreseeable? Example is flat file
loading; is it foreseeable that a certain flat file is made available every
week at the same folder with the same name with the same data quality.
And if this data availability is not foreseeable, then also it is, as you can
imagine, hard to implement periodic scheduling using process chains.
So therefore, if one of these questions applies, then you should work first
on the conceptual side of administration before implementing process
chains. This means, as we can see on slide number eight, that you have to
think of building administration procedures or operation procedures in
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 7
order to support process chain implementation. Means you have to fix
and you have to discuss certain topics like data ownership and availability
of data? Means also support organization: who monitors the process
chains and who supports process chains?
Then, also, the next thing is that you have to give guidelines for process
chain implementation and for process chain administration. What do I do
if something fails? How to react in case of error. What are repair
procedures? These are very important questions to be answered before
starting automating a scenario using process chains.
The next thing, which should be included in such administration
procedures, are, as you can see on slide nine, naming conventions.
Also, it is important to think of transport management guidelines for
process chains. My recommendation is that you transport process chains
from the development system to the test system. You test it then, and then
you transport it to production because process chains are no ad hoc
scheduling tool like info packages are, but process chains are really
something static, a static tool, which is used for periodic scheduling.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 8
Therefore, process chains should be transported from development system
to test and then to production system.
Now let’s come to the next part in this presentation, and this is the part
from processes to process chains. We will now come to page number 11.
In this chapter I now I want to give you advice on how to collect relevant
processes that have to run within the process chain and then how to
distribute these processes to single process chains.
First, you have to collect all processes that have to run before data can be
released to the end users. This is not only our data-load processes; it’s
also administration processes like change runs, like roll-up of aggregates
and also reporting agent processes.
Then when having all these processes, you have to think of what are the
time windows for my process chains? When can I start the process chain
during the night and when does it need to finish in order that data is
available early in the morning for the end users?
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 9
Then finally, you have to think of special dependencies or priorities. Is
something depending on another thing or is something more important to
succeed in a process chain than another process?
So on slide 12 this is an example, on a central document, that collects all
processes in order to prepare the final modeling of the process chain.
When we now think of distributing processes to process chains we might
use some typical criteria for doing this. These criteria, you can find them
now on page 13 and page 14. The criteria I give there are ordered
according to their priority. Means that the first criteria, frequency, seems
to me being the most important criteria.
This is because frequency is a criteria, which leads automatically to
separately scheduled process chains, so if one process needs to be
scheduled daily and the other needs to be scheduled monthly, then in 99%
of the cases you need to build separately scheduled process chains in order
to be started, once a day or once a week.
Next criteria that will help you, distributing processes to process chains, is
the business scenario, which is in question. Means the reporting scenario,
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 10
for example inventory management or headcount analysis. The criteria
business scenario, can lead to separate scheduling but is most of the time
used for administration purposes. Means that you might have different
support teams and different support organizations for different business
topics, for different business scenarios.
Next criteria is the data type you load. Means whether loading master data
or transaction data. This is not a criteria, which leads automatically to
separately scheduled process chains but which will very often be used for
creation of sub chains: one sub chain for master data, another one for
transaction data.
So next criteria on slide 14 is source systems. The type of source system
might sometimes also lead to separate scheduling…availability of source
systems or data in the source systems will be different. So that will be
used for creating sub chains.
And the last criteria applies for BW landscapes, where we find multiple
BW’s.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 11
Usually, as you can see, as a final conclusion, process chain design and
distribution of processes to process chains will depend heavily on dataload processes, and whenever you have something to be scheduled that is
not depending on any data load, a process chain that does not need to
include a data load, then you might schedule this group of processes
totally independent from all other process chains relying on data loads.
The next very, very, very important topic is that when then you can see
how your processes will be grouped to process chains that you have to see
that the complexity of a single chain should still be reasonable. Means
you should not include all the processes you have in a single process chain
because when having over 100, 200 processes in one chain, then
administration of this chain will be very difficult.
So therefore, to keep it simple and to keep administration simple, you
should think of then splitting up this very big chain in several sub chains.
The benefits you will then have is that you can better visualize
dependencies, better visualize lock situation and administration will be
simplified.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 12
To do this, as you can see, you can use the process type “local process
chain” which you can find in the process chain maintenance transaction
RSPC.
When doing this, you create a so-called process chain hierarchy. My
recommendation on processes hierarchies is that you should not have, in
one hierarchy, more than two to three hierarchy levels.
Now we come to slide number 19 to the general modeling principles. As
you can see, there are five basic principles I will mention. On one hand,
technical considerations like maximum performance and maximum
stability, and then on business side fulfilling all my requirements and
doing it as less cost as possible.
So now we are on page 20. First topic I want to talk about is how to avoid
unwanted dependencies in the process chain. This is about how to
improve termination security of a process chain.
The first example you can find there is on modeling the links in a process
chain that link processes to each other. The color of these links, should be
always based on the priority of a single process.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 13
An example is that in some cases the failure on a single text load should
not stop the whole process chain. Therefore, in the good example, on the
right side, you see that the link between the text load and the attribute
change run is modeled with green/red. Means the attribute change runs in
all cases, even if the text load failed.
In order to use this green/red link, you should, as prerequisite, avoid the
undefined yellow status on processes by using 2 customizing settings:
The one is that you customize the traffic light colors in BW (customizing
transaction SPRO). The next customizing setting that might help you is
using the polling flag.
Next topic is on how to avoid unwanted dependencies on process chain
level. The first thing is that you should only use links between process
chains or external triggers to process chains when they are needed. In the
example we have an HR transaction data load and an SD transaction data
load and they’re probably not dependent on each other. They should not
be linked together in one meta chain but they should be simply scheduled
at different times, not using any link.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 14
Then, when working with multiple BW production systems, you should
think of which is the leading system for triggering all processing. Is it like
on the left side on slide 21, the start process in the global process chain,
which is triggering the processing in the local systems, or is the local
systems finishing their processing and then signaling the global process
chain that it can now start?
Now we come to page 22 and it is about how to avoid lock situations.
When having complex process chains, we have the risk that we implement
processes that lock each other and that makes the process chain fail. On
this slide you will find some example on process types where locking can
occur and where parallel scheduling can create deadlocks.
For example, the hierarchy and attribute change run which is temporarily
locking big parts of the BW system.
The other thing, which can happen, is that you use the waiting time which you can find in the context menu in the design view in the process
chain - that you use this waiting time for modeling purposes. It is not
meant for that. This waiting time you can set per process is used for
debugging a process, for making a job wait in order that you can debug it,
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 15
but it is not meant for modeling purposes. It makes the whole process
chain wait, and not only the process.
So now we come to page 23, and to avoid such lock situations you should
always carefully check warnings saying that the process is already used in
another chain. So the tool will signal you as soon as you use a process
twice in two process chains.
Then finally, depending on the size of your system, you will have a
competition between two modeling principles, between parallelization and
locking. Means the bigger your systems are, the more you have to work
on minimizing lock situations because you can use heavy parallelization.
And the smaller your system is, the more you have to work on maximum
parallelization. These two principles have to be checked against each
other.
How the parallelization of processes can be achieved in a system, this we
will now see within the next modeling principle on slide 24. There you
see that parallelization within process chain scheduling occurs on all
levels. The level we can influence in process chain modeling is that we
can schedule two processes at the same time in a process chain.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 16
The other thing is that we can schedule two process chains at the same
time.
But I want to you advise you with this slide that there are other ways of
achieving parallelization, which are below process chain or on top of
process chain modeling.
Below process chain modeling, you have the option of customizing
parallelization on some process types, and this we will see on the next
slide, that a single process is already using more than one basis work
process.
So, as you can see on slide 25, on some process types you use in the
process chain you can customize parallelization.
As soon as you customize a parallelization in one of these settings, you
will achieve parallel dialog processes to be used during the run of the
process chain. Means that in that case, and only in that case, these process
types will split up dialog processes during the run of process chain. This
also needs to be considered for system sizing !
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 17
And on the next slide, just some information on the processing option in
the info package and its influence on using one batch process or parallel
dialog processes between the PSA and final data targets.
So next very important message on slide 26, is that you should model
balanced parallel tracks. Means you should investigate on the run time of
a single process, schedule the process chain and you should distribute your
processes to parallel tracks so that the difference between the end time of
one track and the end time of other parallel tracks should be minimized.
In this example we have, then, one parallel track running six minutes,
another one running seven minutes and the long attribute load on business
partner will run for eight minutes. This makes the AND only waiting for
two minutes to collect all events.
Now we come to page 28, and there we have some important information
that whenever the chain gets executed, then the processes in the chain will
be planned in background processes. Just in the cases where you
customize parallelization, like mentioned before, then you will have
additional dialog processes. Means that you can count the number of
processes to be used in a process chain by adding the number of parallel
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 18
processes you can have at a time plus the number of parallel dialog
processes that might be used in addition.
Next important message on this slide, on slide 28, is that if you specify no
server on which a process chain should run, then you use, as you know,
SAP load-balancing. This means that then the process chain will start
running on the instance defined in the profile parameter given on this
slide. If then no resources are available on that instance, then the job will
be converted to a time-based job and will be started again by the next time
scheduler. And then this job might go to another instance and might be
scheduled on a different server, where there are basis resources available.
The other way of scheduling a process chain would be setting the
background server attribute in the process chain maintenance. This means
that you define the background server on which the whole process chain
should run. So the target server will be entered in each job when the
process chain is scheduled and then all the processes run on one
background server.
Means that your whole processing might switch the background server
from time to time if you set this attribute. So therefore, our
recommendation on setting this attribute or not is that you have to consider
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 19
two important topics when choosing between load-balancing or precise
scheduling on a server.
The first topic is when you have a comparably small system and when you
are short of base resources, then your most important consideration will be
controlling the overall resource consumption of process chains.
Then you might set this background server attribute or then you might also
set up separate servers that you use for background processing or dialog
processing. Means one server having a lot of background processes used
for nightly scheduling and another server with dialog processes used for
daily reporting.
If you have a sufficiently big basis system, then your most important topic
will be high availability and performance. How can I guarantee optimal
performance and optimal availability of data, finding my data targets?
Then (and this applies to most of the cases) you will preferably use load
balancing because then you can make optimal use of your basis resources
by distributing your processes and process chains over several background
servers. Also then, you can guarantee that whenever one server is down
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 20
that then the other servers might take care of the process chains scheduling
during that night.
Finally, you will then test every process chain on resource consumption
and run time before going live and then you can then enter it in a central
and overall scheduling overview, like you can see on page 31, and this
overview will then, for example, on process chain level, contain the
available resources you have and the consumption of these resources in
terms of number of parallel processes and run time.
Now, to come to an end, we now will have a short investigation on the last
two points. First, you have to guarantee also, in your process chains, the
correct sequence of administration processes. For example: First
aggregate data and then compress the data.
Now we come to page 33 and there we see a proposed master dataload
sequence of first attributes, then hierarchies, then text, because text are not
as important as attributes and hierarchies because text loads do not require
any change run after them. So then they probably can be scheduled
separately, using separate process chains. Also, really important, when
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 21
you use independent load scenarios for master data, think of coordinating
the change run.
So finally, I want to tell you about the difference between scheduling
process chains in comparison to existing old BW functionality where you
have InfoPackage groups. When these are scheduled you have a lot of
flags on info package level on info cube maintenance level and an ODS
objective maintenance level that trigger subsequently processes like
deletion of data targets or roll-up of aggregates or activation of ODS
objective data and BW.
This flags have been replaced by according process types in the process
chains. Means that if an info package is started in the process chain, then
these flags are ignored and the respective process type must be scheduled
in that process chain.
The overall message behind this is to say that it’s two different worlds.
One world is scheduling the InfoPackages and using the flags on object
level, and the other world is using process chains for scheduling.
Everything that has to run until the data is finally available should be part
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 22
of the process chains and you should not use for one administration
scenario, info package groups and process chains at the same time. And
that you just use info packages only when you do ad hoc scheduling, like
you do when scheduling repair full uploads or when initializing data loads.
I hereby want to close this conference call.
O. Mayer
Thank you, Rudolf. Let’s open up the lines for questions and answers,
Bill.
Coordinator
The first line will open as Frederick Pinchon at Orenso. Please go ahead.
F. Pinchon
Yes, hello. There was a feature that I missed during the process chain.
It’s a feature picture. I would like to be able to type in for object name or
data target name and to find it in the maintenance of the process chain. Is
it a feature that is likely to be implemented in a future release?
R. Hennecke
Yes, that’s right. This is because the info object itself is not a process and
therefore you cannot see where the info object is used. I know what you
mean; you want to know in which chain it is used.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 23
F. Pinchon
Yes.
R. Hennecke
This is currently not available but I will mention this to our development.
Thanks for this input.
F. Pinchon
Thank you.
Coordinator
Thank you, the next line we’ll open is Chung Ching at Deloitte and
Touche, please go ahead.
C. Ching
Hello. We have some question about restarts. When one of the process in
the process chains fail, is there any way the restart features when you right
mouse, left mouse kit, you can see that restart features but that one does
not work.
R. Hennecke
Not all process types allow restarting and which process types allow
restarting can be seen in the process chain maintenance when you click in
the menu on settings, maintain process types. Then you can see all the
different process types and in the process type maintenance, there’s a flag
“restartable” and when this flat is set, then the process type can be
restarted.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 24
C. Ching
My second question is about a DB statistic. I think that’s a process, DB
statistic)
R. Hennecke
Yes, on page three the DB statistics process means, the DB statistics
update. But the question is whether you use this process or not depends
also on your database. On some databases, scheduling and refreshing of
database statistics is done globally for the whole system. You might also
look at the collective note on BW database performance for BW 3.0.
C. Ching
Okay, last question is, anyway, you can provide the process chain copies
features?
R. Hennecke
There is planned a process chain copy feature but currently it is not
available.
C. Ching
Okay, thank you.
Coordinator
Next line we’ll open is the line of Craig Handjian at Exxon/Mobil. Please
go ahead.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 25
C. Handjian
I’ve got two questions. The first question is expand a little bit more on
that copy feature. I wanted to ask, will they have something that will just
let us copy chain A to chain B or if you look at slide 16, where you have
the example of how to take a large chain and break it into two. Will you
be able to take a section of a large chain and remove it and copy it into
another chain? Because if I, I think now currently you’d have to delete all
the process variants from the larger chain and rebuild it, correct?
R. Hennecke
Yes, this is right, yes.
C. Handjian
So will there be in that copy feature, would we be able to copy just a piece
of a larger chain?
R. Hennecke
With the copy feature, it will be possible to copy the whole chain. This
means you will have this big chain twice and unfortunately, you still then
have to remove all processes you do not need.
C. Handjian
Yes.
R. Hennecke
This is how it works. Actually, there’s no plan on copying single
processes between chains because there’s also high risk in copying it to
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 26
another chain. A move would be acceptable, I would say, but a copy is
very dangerous as of the locks that can occur.
C. Handjian
Got you. My second question is with regards to the polling flat that you
talked about on slide 20. You did mention it takes up one additional batch
process. Can you talk about, does that pulling start when just one process
chain kicks off and it ends when all the process chains have succeeded?
Or how does that work in conjunction with the chains that are running in
your system?
R. Hennecke
This polling occurs always on one single process chain.
C. Handjian
So if I had 15 separate process chains…I’d have to…
R. Hennecke
Then you should not set the polling flag on all process chains but only
where you want to have nearly 100% termination security. This is because
also by using CCMS termination security improves. Means CCMS is also
triggering an event if processes fail.
C. Handjian
Okay, thank you for your time.
R. Hennecke
You’re welcome.
Coordinator
The next line we’ll open is Steve Rudolph at Monsanto. Please go ahead.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 27
S. Rudolph
Hello, Rudolf. Thank you for the presentation.
R. Hennecke
Hello.
S. Rudolph
I have a question regarding, I’ve been told by several people that the
process chain would be a good use for deletion of PSA data also.
Although it looks like process chains are a little more robust in handling
data loads and everything that is associated with it. Would you
recommend using a process chain for PSA deletion as opposed to batch
scheduling? And can you recommend any practical examples of setting
up process change for something as simple as PSA deletion?
R. Hennecke
Yes, I would recommend the process chains for PSA deletion and one
practical example for doing this would be deleting the change log data of
an ODS object.
S. Rudolph
Very good, and is there any detailled documentation on process chains out
there?
R. Hennecke
On overall usage of process chains?
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 28
S. Rudolph
Yes.
R. Hennecke
We have this conference call of last year: Operating BW 3.0 Using
Process Chains. So it’s in the same folder where you downloaded this
presentation but just in the 2001 to 2002 section. And also have a look in
the BW documentation.
S. Rudolph
Right.
R. Hennecke
And also, process chains are included in the BW standard training:
BW 360 (BW performance and administration).
S. Rudolph
Very good, thank you, Rudolf.
R. Hennecke
Yes, you’re welcome.
Coordinator
The next line we’ll open is Irwin Castelino with Bearing Point. Please go
ahead.
I. Castelino
Yes, I have a question about the process chains where you say they are
local. My question is, are they local by default and what are the difference
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 29
between creating a process chain in RSPC, which is a local process chain,
if there is any.
R. Hennecke
I don’t understand exactly your question. The local process chain, as I
mentioned it in the presentation is just a process chain that you schedule
from another process chain. If you don’t do this, then it is just one process
chain running. Means the local process chain is indicating that it’s a two
level process chain hierarchy where the meta chain is triggering a local
chain. This was meant by that.
I. Castelino
That’s really what I was trying to find out. So basically, I’d have to
schedule one process chain from another process chain and then the
second process chain would be local.
R. Hennecke
Yes, that’s right. If you want to do this, schedule one process chain from
another, then you need to use the local process chain types. If this process
chain is in a different system, then it’s the remote process chain type.
I. Castelino
Okay, one quick question: If I have two process chains, say for sales and
CRM, should they both be in the same process chain or should they be
separate?
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 30
R. Hennecke
It depends on the time when they are scheduled. If one process chain
needs to be scheduled at 2:00 in the morning and the other one at 5:00,
then I would not put it in the same process chain. If you say both have to
run during the night between 2:00 and 4:00, then you can say first, I put
both in the same process chain and then I link the two process chains using
a red/green link.
So in each case, if there is no business relationship between them, then
you should not say if the first one is finishing successfully, then the next
one should start.
Coordinator
Our next question comes from the line of Dennis Wallman with Domtar;
please go ahead.
D. Wallman
Okay, hello, Rudolf. Yes, I’m here. Actually, you gentlemen have
answered my question. It also dealt with the restart process from a failed
process when a step has failed in the process chain. Actually, as we spoke
I started it now because this happened to me yesterday and I’ve done a
restart and everything. So I appreciate this call.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 31
R. Hennecke
Okay, thanks a lot.
O. Mayer
Okay, Bill, let’s take just two more questions because we’re at ten after
here of the hour. So two more questions and then we’ll have to call it
quits and if you have more questions, you can just mail them to me. My email address is oliver.mayer@SAP.com. I will consolidate the questions
and forward them to Rudolf. So go ahead, Bill, and let’s take two more
questions.
Coordinator
All right, the next line we’ll open is Laxmichand Fatnani and Air
Products. Please go ahead.
L. Fatnani
Hello, I have a weird problem. I am from the basis team here and the
problem is mentioned in OSS note 599117. When we execute CCMS and
collect jobs, they just keep running and the dialog word processes as well.
And the end the queue request is rejected on RSPCLOGCHAIN
continuously and then, it holds up the whole processing. And even if I
delete the whole process, it does not free the dialog work process. So I
have to restart the application server. Are this problem connected to the
process chain, which my function team is running?
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 32
R. Hennecke
This might be because when you load data you set this option on load PSA
and data packages in parallel. So this was the slide, let’s see; it was slide
26. When you use that option, then the system will split up already on
source system level during extraction when doing the TRFC one dialog
process per data package. So in BW extraction customizing, you can tell
the system the number of dialog processes to be used for the TRFC. So
then you will have for example four data packages to be sent to BW using
four dialog processes and then on BW for other dialog processes, we’ll
take over the data packages and we’ll write them to PSA. So you might
contact your BW implementation team, what processing option they used
for data loading.
L. Fatnani
Okay, that means this problem of the locking is connected related to table
RSPCLOGCHAIN is connected to process chain?
R. Hennecke
Yes, RSPCLOGCHAIN is in each case a process chain table. This is sure.
So it’s something that comes from the process chain. Now it needs to be
determined whether it is due to bad modeling of process chains.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 33
L. Fatnani
Okay, another question: are there any external resource overhead on the
source systems because of process chains?
R. Hennecke
No, not at all. The thing is, it’s just when you start processes in your
process chain that go to a certain source system data-load processes, that
they take resources from the source system but it’s not different from
scheduling using info packages. So this does not change with process
chains, not at all.
L. Fatnani
Okay, thank you, Rudolf.
R. Hennecke
Yes, bye. You’re welcome.
O. Mayer
Last question.
Coordinator
Thank you, our final question will come from the line of Sam Vareghese
at Oklahoma Gas. Please go ahead.
Paula
Yes, this is Paula actually, but we have an application where we have
several users that need to prepare flat files to implement to BW and
they’re independent of each other. We’ve set it up so when they get their
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 34
data entered, they can trigger the data to be loaded into BW by raising an
event. We were wondering if there was a better way to do that other than
scheduling the load based on the event?
R. Hennecke
Yes, there is one way, or there will be one way. Where are the files? Are
the flat files on the application server?
Paula
Yes, they are.
R. Hennecke
For BW, so…you know the process type operational system command and
this process type, operational system command can be used to do things
on the operational system like looking for files. The bad thing about it is,
that this process type cannot send any status or any instance to other
processes. So it means it can just run but it cannot tell you how it did run
or what did it find.
So means for BW, for a future BW release, it is already planned that you
then use this operational system command and you give a certain string in
and you say, “Please have a look if it is there”.
For now the best thing is yes, to use this trigger.
SAP AMERICA
Host: Margaret Anderson
May 15, 2003/10:00 a.m. CDT
Page 35
Paula
Okay.
O. Mayer
Okay, thank you, of course, Rudolf, for preparing the presentation and
covering this topic in such detail, and based on the number of questions
we had, it was a very good topic and lots of interest in that. Again, I
apologize to you if you didn’t have a chance to ask a question. Please email them to me. Again, my e-mail address is oliver.mayer@SAP.com. I
will consolidate them and forward them to Rudolf.
Then thanks again, everybody, for dialing in. Of course, thanks to Rudolf
also, and then just a reminder; our next topic on May 29th is going to be
data consistency in BW for 3.X systems. My colleague Mike Eecred will
cover that topic. So again, thank you, everybody, for dialing in and thank
you again, Rudolf, for taking the time out to do this presentation.
Coordinator
Ladies and gentlemen, that does conclude your teleconference for today.
Thank you for your participation and for using the AT&T Executive
Teleconference. You may now disconnect.