[7774] in SAPr3-news
Re: Material classification - bad response times
daemon@ATHENA.MIT.EDU (Heiko Zink)
Thu Sep 10 15:57:31 1998
To: sapr3-news@MIT.EDU
Date: Thu, 10 Sep 1998 19:23:47 +0200
From: Heiko Zink <H.Zink@IDS-Scheer.de>
--------------E576C7A6B01465A73657584F
Content-Type: text/plain; charset=3Diso-8859-1
Content-Transfer-Encoding: 8bit
Ich habe in der Vergangenheit eine L=F6sung f=FCr dieses Problem gefunden=
und
bereits bei einem Kunden implementiert.
Diese L=F6sung basiert auf dem Zusammenf=FCgen mehrerer konkreter Merkmal=
e und
speichern in einem Feld des Materialstammes.
Um eine ad=E4quate Performence zu erreichen wurde ein zus=E4tzlicher Matc=
hcode
implementiert.
Wer weitere konkrete Informationen w=FCnscht wende sich doch bitte direkt=
an
mich.
Heiko Zink
H.Zink@IDS-Scheer.de
Peter G. Bouillon schrieb:
> Thomas Mehler <th.mehler@t-online.de> wrote:
> > Our company is using the material classification very intensively. Ou=
r
> > problem is the bad response time (up to 30 minutes per transaction).
> > [...] One of the SAP consultants said that the system is not designe=
d
> > for that kind of usage and that there are now other customers
> > complaining about bad response times in the material classification.
>
> Soweit ich es bisher durchschaut habe, besteht das Problem darin, da=DF
> der Materialstamm nicht nach den Merkmalen geordnet ist, sondern da=DF
> die Merkmale umgekehrt am Material "h=E4ngen". Es d=FCrfte folglich
> erheblich schneller sein, zu einem gegebenen Material dessen Klassen-
> einordnung zu ermitteln als umgekehrt zu einer gegebenen Klassenein-
> ordnung alle Materialien zu finden, die darauf passen.
>
> In letzterem Fall wird der Materialstamm (u.U. mehrfach) sequentiell
> durchsucht, und das schafft tats=E4chlich ein Zeitproblem, weil der
> Materialstamm _gro=DF_ ist. Das Problem l=E4=DFt sich je nach Problems=
tellung
> durch das Anlegen von Indizes verbessern, aber nicht beheben.
>
> In einem mir bekannten Programm ging es um den Telefonverkauf: Kunden
> fragten telefonisch nach Materialien mit bestimmten Eigenschaften,
> und der Verk=E4ufer mu=DFte dann in kurzer Zeit ermitteln, welche passe=
nden
> Materialien die Firma herstellte, und welche davon (von welchem Lager
> aus) lieferbar waren. Da der Dialog am Telefon stattfand, waren lange
> Antwortzeiten nat=FCrlich inakzeptabel. Es stellte sich heraus, da=DF =
das
> SAP-Klassensystem f=FCr diese Aufgabenstellung viel zu langsam war.
>
> Dieses Problem wurde umgangen, indem zun=E4chst, in einem Vorab-Rechenl=
auf,
> zu jedem Material eine Zeichenkette berechnet wurde, die einen Teil der
> Klassifizierung des Materials enthielt. Jedem Material war eine solche
> Zeichenkette zugeordnet. Am Anfang dieser Zeichenkette standen die Wer=
te
> des ersten Suchmerkmals, dann folgten Werte eines zweiten Suchmerkmals,
> und so weiter. Eine Menge Magie sorgte daf=FCr, da=DF die Merkmale und
> deren Reihenfolge dynamisch bestimmt werden konnten (aber nur einmal:
> beim Vorab-Rechenlauf), und da=DF in jeder Zeichenkette sp=E4tere Merkm=
ale
> abh=E4ngig vom Wert der davorstehenden Merkmale sein konnten.
>
> Wenn ein Telefonkunde jetzt nach bestimmten Eigenschaften fragte,
> dann suchte das Programm die passenden Materialien anhand dieser
> vorberechneten Zeichenketten heraus. Das ist erheblich schneller als
> das "echte" Klassifikationssystem von SAP R/3.
>
> Aber dieser Ansatz setzt voraus, da=DF die Reihenfolge der Suchmerkmale
> bei allen Anfragen konstant ist, damit die Vorberechnung funktioniert.
> Wenn also einmal festgelegt ist, da=DF alle Schaufeln nach Farben unter=
-
> gliedert sind, und die roten Schaufeln nach Gewicht, dann ist dies die
> Reihenfolge, die beim Vorab-Rechenlauf in die Zeichenketten gestellt
> wird, und beim eigentlichen Programmlauf kann dann immer nur zun=E4chst
> nach dem Arbeitsmittel, dann (bei Schaufeln) nach der Farbe, dann (bei
> roten Schaufeln) nach dem Gewicht eingegrenzt werden.
>
> Wenn Ihr also die Schaufeln, um im Beispiel zu bleiben, mal zuerst nach
> dem Gewicht eingrenzt und mal zuerst nach der Farbe, dann kommt Ihr mit
> dem Ansatz nicht weiter.
>
> Je nach Komplexit=E4t von Euren Recherchen m=FC=DFt Ihr auch eventuell =
sehr
> lange Zeichenketten vorberechnen.
>
> Ihr bekommt auch Probleme mit dem Ansatz, wenn sich Euere Klassifizieru=
ng
> laufend =E4ndert.
>
> P.
--------------E576C7A6B01465A73657584F
Content-Type: text/html; charset=3Dus-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<DL>Ich habe in der Vergangenheit eine Lösung für dieses Proble=
m
gefunden und bereits bei einem Kunden implementiert. <BR>
Diese Lösung basiert auf dem Zusammenfügen mehrerer konkreter
Merkmale und speichern in einem Feld des Materialstammes. <BR>
Um eine adäquate Performence zu erreichen wurde ein zusätzliche=
r
Matchcode implementiert. <BR>
<BR>
Wer weitere konkrete Informationen wünscht wende sich doch bitte dir=
ekt
an mich. <BR>
<BR>
Heiko Zink <BR>
H.Zink@IDS-Scheer.de <BR>
</DL>
<P>Peter G. Bouillon schrieb:
<BLOCKQUOTE TYPE=3DCITE>Thomas Mehler <th.mehler@t-online.de> wrote:
<BR>> Our company is using the material classification very intensively.
Our
<BR>> problem is the bad response time (up to 30 minutes per transaction).
<BR>> [...] One of the SAP consultants said that the system is not
designed
<BR>> for that kind of usage and that there are now other customers
<BR>> complaining about bad response times in the material classification.
<P>Soweit ich es bisher durchschaut habe, besteht das Problem darin, da&s=
zlig;
<BR>der Materialstamm nicht nach den Merkmalen geordnet ist, sondern da&s=
zlig;
<BR>die Merkmale umgekehrt am Material "hängen". Es dürft=
e
folglich
<BR>erheblich schneller sein, zu einem gegebenen Material dessen Klassen-
<BR>einordnung zu ermitteln als umgekehrt zu einer gegebenen Klassenein-
<BR>ordnung alle Materialien zu finden, die darauf passen.
<P>In letzterem Fall wird der Materialstamm (u.U. mehrfach) sequentiell
<BR>durchsucht, und das schafft tatsächlich ein Zeitproblem, weil
der
<BR>Materialstamm _groß_ ist. Das Problem läßt sic=
h
je nach Problemstellung
<BR>durch das Anlegen von Indizes verbessern, aber nicht beheben.
<P>In einem mir bekannten Programm ging es um den Telefonverkauf:
Kunden
<BR>fragten telefonisch nach Materialien mit bestimmten Eigenschaften,
<BR>und der Verkäufer mußte dann in kurzer Zeit ermitteln, wel=
che
passenden
<BR>Materialien die Firma herstellte, und welche davon (von welchem Lager
<BR>aus) lieferbar waren. Da der Dialog am Telefon stattfand, waren
lange
<BR>Antwortzeiten natürlich inakzeptabel. Es stellte sich hera=
us,
daß das
<BR>SAP-Klassensystem für diese Aufgabenstellung viel zu langsam war.
<P>Dieses Problem wurde umgangen, indem zunächst, in einem Vorab-Rec=
henlauf,
<BR>zu jedem Material eine Zeichenkette berechnet wurde, die einen Teil
der
<BR>Klassifizierung des Materials enthielt. Jedem Material war eine
solche
<BR>Zeichenkette zugeordnet. Am Anfang dieser Zeichenkette standen
die Werte
<BR>des ersten Suchmerkmals, dann folgten Werte eines zweiten Suchmerkmal=
s,
<BR>und so weiter. Eine Menge Magie sorgte dafür, daß
die Merkmale und
<BR>deren Reihenfolge dynamisch bestimmt werden konnten (aber nur einmal:
<BR>beim Vorab-Rechenlauf), und daß in jeder Zeichenkette spät=
ere
Merkmale
<BR>abhängig vom Wert der davorstehenden Merkmale sein konnten.
<P>Wenn ein Telefonkunde jetzt nach bestimmten Eigenschaften fragte,
<BR>dann suchte das Programm die passenden Materialien anhand dieser
<BR>vorberechneten Zeichenketten heraus. Das ist erheblich schnelle=
r
als
<BR>das "echte" Klassifikationssystem von SAP R/3.
<P>Aber dieser Ansatz setzt voraus, daß die Reihenfolge der Suchmer=
kmale
<BR>bei allen Anfragen konstant ist, damit die Vorberechnung funktioniert.
<BR>Wenn also einmal festgelegt ist, daß alle Schaufeln nach Farben
unter-
<BR>gliedert sind, und die roten Schaufeln nach Gewicht, dann ist dies
die
<BR>Reihenfolge, die beim Vorab-Rechenlauf in die Zeichenketten gestellt
<BR>wird, und beim eigentlichen Programmlauf kann dann immer nur zunä=
;chst
<BR>nach dem Arbeitsmittel, dann (bei Schaufeln) nach der Farbe, dann (be=
i
<BR>roten Schaufeln) nach dem Gewicht eingegrenzt werden.
<P>Wenn Ihr also die Schaufeln, um im Beispiel zu bleiben, mal zuerst nac=
h
<BR>dem Gewicht eingrenzt und mal zuerst nach der Farbe, dann kommt Ihr
mit
<BR>dem Ansatz nicht weiter.
<P>Je nach Komplexität von Euren Recherchen müßt Ihr auch
eventuell sehr
<BR>lange Zeichenketten vorberechnen.
<P>Ihr bekommt auch Probleme mit dem Ansatz, wenn sich Euere Klassifizier=
ung
<BR>laufend ändert.
<P>P.</BLOCKQUOTE>
</HTML>
--------------E576C7A6B01465A73657584F--
