DBT in eine itab zum bearbeiten und zurück schreiben

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Wenn Du einen FB der SAP verwendest, dann solltest Du Dir schon vorher anschauen, wie er zu verwenden ist. Tipp: Mache einen Verwendungsnachweis darauf und schau Dir an, wie die SAP (oder andere) ihn aufruft bzw. womit sie ihn füttert.

Mit dem RH_READ_INFTY kannst Du beliebige OM-Infotypen lesen. Die Zieltabelle, die Du angibst, muss die Werte fassen können. Wenn Du jetzt den Parameter INFTY nicht übergibst, woher soll der FB dann wissen, dass Du den IT 5133 haben willst!?

Abgesehen davon muss die Zieltabelle über die entsprechende P-Struktur definiert sein, nicht über die HRP. Du müsstest also den Parameter INFTY mit '5133' versorgen und lt_hrp5133 als TYPE STANDARD TABLE OF P5133 definieren. Dann sollte zumindest der Dump mal weg sein.

- Man meinte,

Frage aus Neugier: Wer ist "man"?

um das Ganze abzurunden sollten die Fehlermeldungen bzw. Erfolgsmeldungen über eine BAPITAB gemacht werden. Hätte ggf. da jemand ein kleines veranschaulichendes Beispiel ?

Das kenne ich eher vom Updaten von PA-Infotypen. Da haste eine Struktur vom Typ BAPIRETURN1, aus der Du dann die (ggf. Fehler-)Meldung extrahieren kannst, die Du bekommen hättest, wenn Du versucht hättest, diese Werte mit SAP-Standardtransaktionen händisch einzupflegen.

Der RH_UPDATE_INFTY liefert eine Tabelle namens ILFCODE zurück, wo vermutlich Fehlerinformationen drinstehen. Habe ich persönlich aber noch nicht benötigt. Der RH_UPDATE_INFTY hat ja auch eine Exception ERROR_DURING_UPDATE zu bieten.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Warum P-Struktur und warum den INFTY mit 5133 versorgen?

Er erhält doch die Struktur von der DB HRP5133, warum funktioniert es damit nicht? Was sollte ich hierzu wissen?

Sicherlich hätte die SAP den FB so bauen könnnen, dass er analysiert, über die Struktur welchen Infotyps die übergebene Tabelle typisiert ist, um dann daraus abzuleiten, welcher Infotyp gelesen werden soll. Aus meiner Sicht gibt es dazu dreierlei zu sagen:

a) Eine solche Analyse bei jedem Aufruf des FB würde auf die Performance drücken. Der Aufrufer weiß ja (hoffentlich), welchen IT er lesen möchte, also warum soll er diese Information nicht einfach mitgeben?
b) Die SAP hat ihre FBs so gebaut, wie sie sie halt gebaut haben. Entweder Du akzeptierst das, oder Du schreibst eine Beschwerde hin. Ob die dort jemanden interessiert, ist eine andere Frage.
c) Erstaunlicherweise hat die SAP den Parameter INFTY optional gemacht. Vermutlich kann man mit dem Baustein verschiedene Infotypen auf einmal lesen. Da brauchste dann aber eine hinreichend generisch typisierte Empfangstabelle und musst dann in ABAP Zeile für Zeile auf den richtigen Datentyp casten.

Was die Tabelle HRP5133 und die Struktur P5133 angeht, so magst Du vielleicht mal googlen, wie man im OM (und ähnlich auch in der PA) eigene Infotypen anlegt. Da muss man immer solche Strukturen anlegen, über die die Transaktion PPCI (OM) bzw. PM01 (PA) dann den Infotypen mitsamt seiner HRP-Tabelle generiert. Soll heißen, die Struktur P5133 war zuerst da, und anhand derer wurde die HRP5133 generiert.

Auch hier kannst Du wieder fragen, warum die SAP das so gemacht hat - oder einfach damit arbeiten. Man kann ja Daten auch recht einfach von P-Struktur in HRP-Tabelle und umgekehrt verschieben: der MOVE-CORRESPONDING-Befehl ist an der Stelle Dein Freund. Die P-Strukturen enthalten aber noch eine Spalte INFTY. Das ist sicherlich für Fälle wie den oben genannten interessant, wenn mit einem Rutsch verschiedene Infotypen über ein generisches Datenkonstrukt eingelesen werden und anschließend auf ihre tatsächlichen Infotypstrukturen verteilt werden sollen.