SAP zu langsam

[Finlay5038]

Judden Morgen zusammen,

ich habe schon wieder (noch immer ) Probleme mit JCO oder lieber gesagt mit SAP.

Ich erstelle in Java einen Auftrag und bekomme ja da eine Auftragsnummer zurück. Mit dieser Nummer schmeiße ich an mein Java-Proggie ein Event, wodurch nun mehrere Threads angesprochen werden. Ein Thread aktualisiert beispielsweise die Anzeige der Order, über die Nummer wird gleich ein neuer SAP-Baustein aufgerufen. Jedoch klappt dies abundzumal, aber öfters bekomme ich auch NullpointerException (Fehler beim Aufruf von Thread/2 Nullpinter.....).

Ich vermute mal, dass da irgendwo SAP eine Rolle spielt. Ich benutzte ja die Nummer für eine neue Funktion, vielleicht sind die Daten dann ja noch nicht da???????

Hat jemand von Euch eine Ahnung warum und wieso das so ist, wie es ist und wie man dem entgegnen kann?

Vielen Dankl für Eure Hilfe.

Unreal_Programmer

[Christian4831]

Hallo Unreal,

kann es sein, dass du mit deiner Threadsynchronisation durcheinander kommst? Wahrscheinlich ist dein 2. Lesethread schneller als dein 1. Thread.

Wahrscheinlich wäre es besser dein Problem nicht nebenläufig sondern eher sequentiell zu lösen!?! Die Kommunikation über JCo erzeugt nun einmal etwas overhead. Des weiteren ist es sehr wahrscheinlich, dass der Baustein / BAPI ab und zu einfach zu lange braucht..

viele Grüsse,

Tim

[Erich410]

Hallo,

ich nehme mal an, Du meinst Verkaufsaufträge.

Wenn Du einen Auftrag an SAP schickst, kann es sein, daß Du schon eine Numer zurückbekommst, bevor der Auftrag auf der Datenbank verbucht ist.

Wenn Du gleich darauf eine Leseroutine anschmeißt, kannes wieder sein, daß der Auftrag noch nicht auf der Datenbank ist.

Eigentlich muß man nach einem Schreibauftrag noch das Bapi BAPI_COMMIT hinterherschicken, damit wirklich verbucht wird.

mfg.
babap

[ewx]

Hallo Unreal,

die Auftträge werden per Verbuchungsbaustein auf die Datenbank geschrieben. Da kann es dann tatsächlich sein (häufig sogar), dass der Verbucher mehrere Sekunden benötigt. Entweder sind keine freien Verbuchungsprozesse im System vorhanden, so dass die Verbuchung selbst warten muss, oder das System ist einfach zu langsam, um den Beleg "in echtzeit" zu verbuchen.

Ich weiss nicht, wie es mit JCO aussieht, aber im ABAP kann man
SET UPDATE TASK LOCAL setzen, was bewirkt, dass der Verbucher im selben Task abgearbeitet wird.
Wenn man dann mit COMMIT WORK AND WAIT. die Verbuchung abschliesst, kann man sicher sein, dass der Verbucher auch zu ende verbucht hat. Es sei denn, die Verbuchung bricht wegen irgendwelchen Gründen ab. Aber dann hat der Commit Work den SUBRC > 0.

Gruß, Enno.

[Willy1492]

COMMIT WORK AND WAIT wartet aber m.E. nur auf die V1-FBs (Verbuchung mit Start sofort).
Der eine oder andere FB zum Fortschreiben von Statistik-Informationen oder Änderungsbelegen kann aber als V2-Verbuchungs-FB definiert sein.
Neben COMMIT WORK AND WAIT hat die Unterscheidung V1/V2 noch Auswirkung auf die Freigabe der Sperren und darauf, ob bei einem Fehler ein ROLLBACK aller bisherigen Änderungen vorangegangener FBs erfolgt.

[Erich410]

Hallo,

ich habe das Problem bei einer von mir geschriebenen SD-Schnittstelle.

Hier werden mehrere Aufträge mit Bezug zueinander angelegt und dann auch noch fakturiert.

Die Belegvernküpfung geht nur dann, wenn der Vorgängerbeleg wirklich echt in der Datenbank angekommen ist.

Ich habe deshalb eine Warteschleife programmiert, die jede Sekunde mal nachsieht, ob das Vorgängerdokument (dessen Nummer ich schon kenne) endlich auf der Datenbank ist.

Genauso sieht es bei der Fakturierung aus (erst mal nachsehen, ob die Aufträge da sind).

mfg.
babap