Suche Fuba oder Klasse
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Hallo,
ich suche Alternativen zu den folgenden Fubas:
1. ALSM_EXCEL_TO_INTERNAL_TABLE
2. /SAPDII/DWB_GET_TABLE_FIELDS
Mit den Funktionen bin ich super zufrienden und die Alternative sollte auch (wenn möglich) die gleichen Paramter usw. haben.
Problem ist, dass die Fubas näher an der BASIS sein müssen, also näher an dem Paket SAP_APPL.
Auf Hilfe würde ich mich sehr freuen.
Eine Klasse die die gleichen Aufgaben wie die Fubas erfüllt und näher am SAP_APPL hängt als die Fubas wäre auch ok.
Hoffe dass mir jemand weiterhelfen kann, da ich schon gesucht habe, und so wie es aussieht keine finden werde (ohne Hilfe).
Zubasa Grüßt
ich suche Alternativen zu den folgenden Fubas:
1. ALSM_EXCEL_TO_INTERNAL_TABLE
2. /SAPDII/DWB_GET_TABLE_FIELDS
Mit den Funktionen bin ich super zufrienden und die Alternative sollte auch (wenn möglich) die gleichen Paramter usw. haben.
Problem ist, dass die Fubas näher an der BASIS sein müssen, also näher an dem Paket SAP_APPL.
Auf Hilfe würde ich mich sehr freuen.
Eine Klasse die die gleichen Aufgaben wie die Fubas erfüllt und näher am SAP_APPL hängt als die Fubas wäre auch ok.
Hoffe dass mir jemand weiterhelfen kann, da ich schon gesucht habe, und so wie es aussieht keine finden werde (ohne Hilfe).
Zubasa Grüßt
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Geh doch einfach noch einmal einen Kaffee beim SAP-Team in Walldorf trinken und frag einfach mal nebenbei die Profis vor Ort.
Wie "nah" soll den der andere Fuba sein.
Mir persönlich ist es z.B. völlig egal, wie nah ein Fuba an irgendetwas anderes ist, solange ich ihn nutzen kann.
Wie definierst Du "näher am SAP_APPL "??? In Zentimeter? Meter? Inch? KM? Minuten? Liter? Anzahl der Fehlermeldungen??
Wie "nah" soll den der andere Fuba sein.
Mir persönlich ist es z.B. völlig egal, wie nah ein Fuba an irgendetwas anderes ist, solange ich ihn nutzen kann.
Wie definierst Du "näher am SAP_APPL "??? In Zentimeter? Meter? Inch? KM? Minuten? Liter? Anzahl der Fehlermeldungen??
Dann kuck doch ins Paket SAP_APPL rein, ob was für dich dabei ist???!!!
Die Frage ist doch: warum suchst du Alternativen zu diesen Bausteinen? Vorgaben? Robustheit gegen mögliche Veränderungen?
@Unit605:
Die Frage ist doch: warum suchst du Alternativen zu diesen Bausteinen? Vorgaben? Robustheit gegen mögliche Veränderungen?
@Unit605:
Diesen Weg halte ich allerdings für sehr gefährlich. Wenn du jeden x-beliebigen Baustein nutzt, dann läufst du ständig Gefahr, dass deine Anwendung nach einem Hinweis/SP/EhP etc. nicht mehr so funktioniert wie gewünscht. Ich persönlich suche mir aus Gründen der Robustheit meistens Bausteine, die im "echten" SAP-Standard verankert sind und nicht irgendwelche Industry Solutions oder sonstiges.Mir persönlich ist es z.B. völlig egal, wie nah ein Fuba an irgendetwas anderes ist, solange ich ihn nutzen kann.
@Casman: Wenn dieser X-beliebig Funktionsbaustein nur einmal im System (im SAP-Standard) vorhanden ist, dann nutze ich DIESEN Funktionsbaustein.casman hat geschrieben:Dann kuck doch ins Paket SAP_APPL rein, ob was für dich dabei ist???!!!
Die Frage ist doch: warum suchst du Alternativen zu diesen Bausteinen? Vorgaben? Robustheit gegen mögliche Veränderungen?
@Unit605:Diesen Weg halte ich allerdings für sehr gefährlich. Wenn du jeden x-beliebigen Baustein nutzt, dann läufst du ständig Gefahr, dass deine Anwendung nach einem Hinweis/SP/EhP etc. nicht mehr so funktioniert wie gewünscht. Ich persönlich suche mir aus Gründen der Robustheit meistens Bausteine, die im "echten" SAP-Standard verankert sind und nicht irgendwelche Industry Solutions oder sonstiges.Mir persönlich ist es z.B. völlig egal, wie nah ein Fuba an irgendetwas anderes ist, solange ich ihn nutzen kann.
Von x-beliebig war hier vom Fragesteller auch nicht gefragt, sondern von einem ganz speziellen, den es anscheinend nur einmal so gibt.
Dann ist es mir wirklich egal, in welchem Paket oder Funktionsgruppe dieser Funktionsbaustein liegt, solange es im SAP Standard ist.
Ich weiß ja nicht, wie Du in solchen Fällen vorgehst. Programmierst Du Dir dann einen eigenen Fuba in einer eigenen Funktionsgruppe oder modifizierst Du jedesmal, wenn der geforderte Funktionsbaustein nicht in "Deinem" gewünschten Paket vorhanden ist?
Ich laufe auch nicht ständig Gefahr, dass dieser SAP Funktionsbaustein nach einem Upgrade oder SP oder EHP nicht mehr richtig läuft.
Die Gefahr besteht wohl eher bei selbstgestrickten Fubas.
Zurückkommend auf die Frage des Threaderstellers: Da es diesen gewünschten Fuba nur einmal im SAP-System ( im SAP-Standard ) gibt, WAS ist DEIN Vorschlag für den Threadersteller?
Mein Vorschlag: Nutze DIESEN einen bestehenden funktionierend Funktionsbaustein. Und nun wieder. Mir ist es egal, ob dieser nun im Paket SAP_APPL ist oder nicht.
Da diese Vorgehen für Dich zu gefährlich ist, mache einen besseren Vorschlag.
Hey Unit605,
das sollte kein Angriff sein, sondern Anstoß zur Diskussion...
Mir geht es nicht darum, in welchem Paket ein Baustein ist oder nicht, sondern darum, wie resistent ist meine Anwendung gegen plötzliche Veränderungen?
Verstehst du, auf was ich hinauswill? Ein interner Entwickler mag das anders sehen...
Meine Empfehlung für den Thread-Ersteller lautet: Wenn du diese Bausteine nicht nutzen willst, kopier den ALSM in einen eigenen und nutze anstatt den /SAPDII/DWB_GET_TABLE_FIELDS die SAP-eigenen RTTS. Fädich!
das sollte kein Angriff sein, sondern Anstoß zur Diskussion...
Mir geht es nicht darum, in welchem Paket ein Baustein ist oder nicht, sondern darum, wie resistent ist meine Anwendung gegen plötzliche Veränderungen?
Doch das läufst du! SAP kann jederzeit die Aufrufschnittstelle bzw. den Inhalt des Bausteins verändern, ohne dir Bescheid zu geben. Somit ist dein Programm im eigentlichen "Sinne" nicht stabil. Einen Baustein wie z.B. /SAPDII/DWB_GET_TABLE_FIELDS, der auch noch aus einem speziellen Namensraum ist (das ist dann für mich kein "echter" SAP-Standard im eigentlichen Sinne) würde ich im Leben nicht nutzen. Lieber würde ich ihn in den Z-Namensraum kopieren und damit weiterarbeiten. Das kann aber auch daran liegen, dass ich Externer ABAP-Entwickler bin und nachdem ich meine Leistung abgeliefert habe, meist den Kunden verlasse. Ich habe dann keine Lust, dass meine Kunden nach Einspielen eines Hinweises anrufen und sagen: "Herr Casman, Ihre Anwendung dumped."laufe auch nicht ständig Gefahr, dass dieser SAP Funktionsbaustein nach einem Upgrade oder SP oder EHP nicht mehr richtig läuft.
Die Gefahr besteht wohl eher bei selbstgestrickten Fubas.
Verstehst du, auf was ich hinauswill? Ein interner Entwickler mag das anders sehen...
Meine Empfehlung für den Thread-Ersteller lautet: Wenn du diese Bausteine nicht nutzen willst, kopier den ALSM in einen eigenen und nutze anstatt den /SAPDII/DWB_GET_TABLE_FIELDS die SAP-eigenen RTTS. Fädich!
Hi,
also es geht darum, dass die Kunden nicht sagen sollen:"Herr Zubasa, Ihre Anwendung dumped.".
Kann ja sein dass die Fubas mal verändert werden und dann bei meinem Programm nichts mehr läuft.
Kennt jemand andere Fubas oder Klassen, bei denen dass nicht passieren dürfte?
Gruß, Zubasa
also es geht darum, dass die Kunden nicht sagen sollen:"Herr Zubasa, Ihre Anwendung dumped.".
Kann ja sein dass die Fubas mal verändert werden und dann bei meinem Programm nichts mehr läuft.
Kennt jemand andere Fubas oder Klassen, bei denen dass nicht passieren dürfte?
@Casman: Was genau meinst du damit?Meine Empfehlung für den Thread-Ersteller lautet: Wenn du diese Bausteine nicht nutzen willst, kopier den ALSM in einen eigenen und nutze anstatt den /SAPDII/DWB_GET_TABLE_FIELDS die SAP-eigenen RTTS. Fädich!
Gruß, Zubasa
Was würdest Du den mit anderen Fubas machen?Zubasa hat geschrieben:@Casman: Achso ja klar, soory hatte ein blackout. Is klar was du damit meinst.
Aber gibt es den sonst keine anderen Fubas oder Klassen (Damit ich das nicht machen muss)?
Grüße, Zubasa
Lt. Empfehlung von Casman müsstest Du diese auch in den Kundennamensraum kopieren.Zubasa hat geschrieben: Mit den Funktionen bin ich super zufrienden und die Alternative sollte auch (wenn möglich) die gleichen Paramter usw. haben.
Dann mach doch einfach das, was Casman Dir empfiehlt und kopiere den ALSM in den Kundennamesraum und nutze diesen.
Ich dagegen distanziere mich von solchen Empfehlungen, speziell in diesem Fall.
casman hat geschrieben:Hey Unit605,
das sollte kein Angriff sein, sondern Anstoß zur Diskussion...
Mir geht es nicht darum, in welchem Paket ein Baustein ist oder nicht, sondern darum, wie resistent ist meine Anwendung gegen plötzliche Veränderungen?
Doch das läufst du! SAP kann jederzeit die Aufrufschnittstelle bzw. den Inhalt des Bausteins verändern, ohne dir Bescheid zu geben. Somit ist dein Programm im eigentlichen "Sinne" nicht stabil. Einen Baustein wie z.B. /SAPDII/DWB_GET_TABLE_FIELDS, der auch noch aus einem speziellen Namensraum ist (das ist dann für mich kein "echter" SAP-Standard im eigentlichen Sinne) würde ich im Leben nicht nutzen. Lieber würde ich ihn in den Z-Namensraum kopieren und damit weiterarbeiten. Das kann aber auch daran liegen, dass ich Externer ABAP-Entwickler bin und nachdem ich meine Leistung abgeliefert habe, meist den Kunden verlasse. Ich habe dann keine Lust, dass meine Kunden nach Einspielen eines Hinweises anrufen und sagen: "Herr Casman, Ihre Anwendung dumped."laufe auch nicht ständig Gefahr, dass dieser SAP Funktionsbaustein nach einem Upgrade oder SP oder EHP nicht mehr richtig läuft.
Die Gefahr besteht wohl eher bei selbstgestrickten Fubas.
Verstehst du, auf was ich hinauswill? Ein interner Entwickler mag das anders sehen...
Meine Empfehlung für den Thread-Ersteller lautet: Wenn du diese Bausteine nicht nutzen willst, kopier den ALSM in einen eigenen und nutze anstatt den /SAPDII/DWB_GET_TABLE_FIELDS die SAP-eigenen RTTS. Fädich!
Hallo Casman,
ich hoffe doch sehr, dass Du Dich in dem letzten Statement des öfteren einfach nur mal verschrieben oder vertan hast.
Du glaubst doch nicht allerernstes, dass Deine Programme sicherer sind, wenn Du alles mögliche in den Kundennamesraum kopierst. Das ist ein indisches Märchen, an den alle indischen Programmierer glauben.
Gerade DESWEGEN ist es empfohlen, den SAP-Standard zu nutzen. (ALSM)
SAP ändert ständig Programme und Fubas. Wenn Du den SAP Standard nutzt, bist Du auf der sichersten Seite.
Alles andere ist Erklärungsbedürftig!
Du kannst nur hoffen, nie mit SAP BW (jetzte BI?) in Verbindung zu kommen. Du müsstest wahrscheinlich das komplette BW (BI?) neu erfinden bzw. umkopieren.
Hey Unit605, hi Zubasa,
Moment moment, jetzt reden wir aber aneinander vorbei. Ich kopiere mir doch nicht jeden Mist in den eigenen Namensraum...das wäre in der Tat etwas verwegen.
Vielmehr schaue ich mir die Bausteine an, kucke was machen sie, welchen Business-Background haben sie, wo und wie oft werden sie verwendet...danach entscheide ich mich für einen Einsatz des Bausteins oder kopiere diesen eben. Hierbei unterscheide ich z.B. ob ich im FI entwickel und einen FI-Baustein benutze, oder ob ich im MM entwickle und einen FI-Baustein benutze. Letzteres ist gefährlich, da ich einen Baustein eines gänzlich anderen Moduls verwende.
Bsp: Einen Baustein CONVERT_TO_LOCAL_CURRENCY würde ich niemals kopieren, weil wie Unit605 ja erwähnt hat, ich mich sonst vom SAP Standard abhänge. Dies ist für viele Anwendungen natürlich nicht sinnvoll, ja sogar gefährlich. Außerdem wird der Baustein x-fach verwendet, was plötzliche Änderungen nahezu ausschließt.
Bsp2: Einen Baustein wie /SAPDII/DWB_GET_TABLE_FIELDS würde ich im Leben nicht nutzen, da er 1. nur einen SELECT auf die DD03L macht und 2. zu einer speziellen Lösung, dem Vehicle Management System gehört. Auch liefert der Verwendungsnachweis keinerlei Ergebnisse, so dass anzunehmen ist, der Baustein wird nicht (mehr) verwendet. Hier läuft man in der Tat Gefahr, dass die jeweilgen verantwortlichen Entwickler einfach mal was umstellen, sei es am Coding oder an den Aufrufschnittstellen.
Bsp3: Den Baustein ALSM_EXCEL_TO_INTERNAL_TABLE kann man prinzipiell verwenden, da er nur ein paar OLE-Funktionen kapselt. Allerdings gehört er zur Anlagenbuchhaltung-Altdatenübernahme und ist keinen Teil der SAP Frontend-Services. Damit ist es Glückssache, ob der Baustein stabil bleibt oder nicht. Hier muss jeder selbst entscheiden, wie er verfährt.
Prinzipiell halte ich aber an meinem Statement fest, dass ich als Externer Entwickler vorrangig die Funktionssicherheit meiner Anwendung sicherzustellen habe. Somit wird es mir immer wieder passieren, dass ich mir einen Baustein kopiere, da er 1. das macht was ich brauche und 2. ich grundlegende Änderungen an diesem Baustein nicht voraussehen kann.
Moment moment, jetzt reden wir aber aneinander vorbei. Ich kopiere mir doch nicht jeden Mist in den eigenen Namensraum...das wäre in der Tat etwas verwegen.
Vielmehr schaue ich mir die Bausteine an, kucke was machen sie, welchen Business-Background haben sie, wo und wie oft werden sie verwendet...danach entscheide ich mich für einen Einsatz des Bausteins oder kopiere diesen eben. Hierbei unterscheide ich z.B. ob ich im FI entwickel und einen FI-Baustein benutze, oder ob ich im MM entwickle und einen FI-Baustein benutze. Letzteres ist gefährlich, da ich einen Baustein eines gänzlich anderen Moduls verwende.
Bsp: Einen Baustein CONVERT_TO_LOCAL_CURRENCY würde ich niemals kopieren, weil wie Unit605 ja erwähnt hat, ich mich sonst vom SAP Standard abhänge. Dies ist für viele Anwendungen natürlich nicht sinnvoll, ja sogar gefährlich. Außerdem wird der Baustein x-fach verwendet, was plötzliche Änderungen nahezu ausschließt.
Bsp2: Einen Baustein wie /SAPDII/DWB_GET_TABLE_FIELDS würde ich im Leben nicht nutzen, da er 1. nur einen SELECT auf die DD03L macht und 2. zu einer speziellen Lösung, dem Vehicle Management System gehört. Auch liefert der Verwendungsnachweis keinerlei Ergebnisse, so dass anzunehmen ist, der Baustein wird nicht (mehr) verwendet. Hier läuft man in der Tat Gefahr, dass die jeweilgen verantwortlichen Entwickler einfach mal was umstellen, sei es am Coding oder an den Aufrufschnittstellen.
Bsp3: Den Baustein ALSM_EXCEL_TO_INTERNAL_TABLE kann man prinzipiell verwenden, da er nur ein paar OLE-Funktionen kapselt. Allerdings gehört er zur Anlagenbuchhaltung-Altdatenübernahme und ist keinen Teil der SAP Frontend-Services. Damit ist es Glückssache, ob der Baustein stabil bleibt oder nicht. Hier muss jeder selbst entscheiden, wie er verfährt.
Prinzipiell halte ich aber an meinem Statement fest, dass ich als Externer Entwickler vorrangig die Funktionssicherheit meiner Anwendung sicherzustellen habe. Somit wird es mir immer wieder passieren, dass ich mir einen Baustein kopiere, da er 1. das macht was ich brauche und 2. ich grundlegende Änderungen an diesem Baustein nicht voraussehen kann.
Hallo zusammen,
ich mische mich auch noch kurz in die Diskussion ein
Vor kurzem war ich bei SAP bei einem Partnerinfotag und dort gab es eine Diskussionsrunde mit der SAP Entwicklung zum Informationsaustausch. Dabei kam u. a. auch eine Frage in der Richtung auf, welche Funktionsbausteine man denn ganz offiziell verwenden darf und sollte. Darauf war die Antwort von SAP, dass grundsätzlich jeder Funktionsbaustein - der ausgeliefert wurde - auch verwendet werden darf. Früher war das Thema "Freigabe" mal angedacht... das wurde aber in letzter Zeit nicht mehr konsequent durchgehalten und der Großteil der neueren Bausteine haben keinen Freigabestatus. Trotzdem lautet die Vorgabe von SAP, dass ausgelieferte Fubas eigentlich nur noch zusätzliche optionale Parameter erhalten sollten. I. d. R. kann also jeder Fuba verwendet werden...
Ich ganz persönlich würde eine Baustein wie /SAPDII/DWB_GET_TABLE_FIELDS auch nicht unbedingt nehmen.... aber solange der Baustein im Standardnamensraum liegt und schon über längere Zeit existiert, wie bspw. der ALSM_EXCEL_TO_INTERNAL_TABLE, hätte ich da überhaupt kein Problem den auch in meinen Programmen zu verwenden! Und das sage ich durchaus auch als externer Berater... im Zweifelsfall ist die Wahrscheinlichkeit, dass eine Änderung am SAP-Standard in einem Standard-Funktionsbaustein nachgezogen wird (und zwar intern im Fuba ohne Anpassung der Schnittstelle), so dass er weiterhin funktioniert deutlich höher, wie dass ganz automatisch der kundeneigene Fuba an die neuen Bedingungen angepasst wird.
Gruß
Christian
ich mische mich auch noch kurz in die Diskussion ein
Vor kurzem war ich bei SAP bei einem Partnerinfotag und dort gab es eine Diskussionsrunde mit der SAP Entwicklung zum Informationsaustausch. Dabei kam u. a. auch eine Frage in der Richtung auf, welche Funktionsbausteine man denn ganz offiziell verwenden darf und sollte. Darauf war die Antwort von SAP, dass grundsätzlich jeder Funktionsbaustein - der ausgeliefert wurde - auch verwendet werden darf. Früher war das Thema "Freigabe" mal angedacht... das wurde aber in letzter Zeit nicht mehr konsequent durchgehalten und der Großteil der neueren Bausteine haben keinen Freigabestatus. Trotzdem lautet die Vorgabe von SAP, dass ausgelieferte Fubas eigentlich nur noch zusätzliche optionale Parameter erhalten sollten. I. d. R. kann also jeder Fuba verwendet werden...
Ich ganz persönlich würde eine Baustein wie /SAPDII/DWB_GET_TABLE_FIELDS auch nicht unbedingt nehmen.... aber solange der Baustein im Standardnamensraum liegt und schon über längere Zeit existiert, wie bspw. der ALSM_EXCEL_TO_INTERNAL_TABLE, hätte ich da überhaupt kein Problem den auch in meinen Programmen zu verwenden! Und das sage ich durchaus auch als externer Berater... im Zweifelsfall ist die Wahrscheinlichkeit, dass eine Änderung am SAP-Standard in einem Standard-Funktionsbaustein nachgezogen wird (und zwar intern im Fuba ohne Anpassung der Schnittstelle), so dass er weiterhin funktioniert deutlich höher, wie dass ganz automatisch der kundeneigene Fuba an die neuen Bedingungen angepasst wird.
Gruß
Christian
Hallo ChrisB,
Danke für Dein Statement.
Vielleicht bin ich schon zu lange im Geschäft, aber ich ging davon aus, dass Deine Informationen über das Verwenden von SAP Funktionsbaustein, insbesondere das mit den Änderungen des Fubas, allgemein bekannt ist.
Die Eingangsfrage von Zubasa ist mir allerdings immer noch ein Rätsel.
Auch als alter Hase lernt man ja nie aus
Danke für Dein Statement.
Vielleicht bin ich schon zu lange im Geschäft, aber ich ging davon aus, dass Deine Informationen über das Verwenden von SAP Funktionsbaustein, insbesondere das mit den Änderungen des Fubas, allgemein bekannt ist.
Die Eingangsfrage von Zubasa ist mir allerdings immer noch ein Rätsel.
Wäre schön, wenn Zubasa etwas Licht ins Dunkle bringen würde.Mit den Funktionen bin ich super zufrienden und die Alternative sollte auch (wenn möglich) die gleichen Paramter usw. haben.
Problem ist, dass die Fubas näher an der BASIS sein müssen, also näher an dem Paket SAP_APPL.
Auch als alter Hase lernt man ja nie aus
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
3233
Views
Views
2
Antw.
Antw.
2457
Views
Views
Suche FuBa zum Fertigungsauftrag anlegen
von Andreas G » 28.11.2005 08:54 • Verfasst in Material Management & Produktionsplanung
von Andreas G » 28.11.2005 08:54 • Verfasst in Material Management & Produktionsplanung
16
Antw.
Antw.
6730
Views
Views
0
Antw.
Antw.
696
Views
Views
Suche FUBA um Änderungsantrag abzuändern
von carlie » 29.01.2018 14:51 • Verfasst in ABAP® für Anfänger
von carlie » 29.01.2018 14:51 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
1109
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.