modelling aspects in process chains - transcript

SAP AMERICAHost: Margaret Anderson

May 15, 2003/10:00 a.m. CDT

SAP AMERICA

May 15, 200310: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 listen-

only 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.


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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?


May 15, 2003/10:00 a.m. CDT

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,


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

Usually, as you can see, as a final conclusion, process chain design and

distribution of processes to process chains will depend heavily on data-

load 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.


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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,


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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 !


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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?


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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?


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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 e-

mail address is [email protected]. 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?

mailto:[email protected]


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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


May 15, 2003/10:00 a.m. CDT

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.


May 15, 2003/10:00 a.m. CDT

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 e-

mail them to me. Again, my e-mail address is [email protected]. 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.

modelling aspects in process chains - transcript

Documents

process chains

term process

equal process type

single process types

cdt page

page number

margaret anderson

bw administration