Möchte man in unserem Beispiel mit der Anzahl Spieler 0, wie im Klassiker War Games, das beide Spieler strategisch vorgehen, ist im Unterprogramm „spielen“ folgendes zu ändern.
Es wird zuerst, ist der Spieler SAP am Zug, der Defensivzug durch die Summe der Zeilen,Spalten oder Diagonalen mit dem Wert 10 bestimmt. Danach der Offensivzug mit der Summe 2. Ist der Spieler USR am Zug genau umgekehrt. Ist Defensiv gegen 2 vorzugehen und anschließend ob die Summe 10 zum Gewinn führt.
Im Artikel (Link) erwähnte ich eine Offensiv- und Defensivstrategie für den alten Übungscode den ich zur Anschauung (Link) überarbeitet habe.
Strategiedaten eingeblendet damit sie ohne Debugger im Spielverlauf beobachtet werden können.
Im Code sehen wir, das zunächst Spielzüge wie im Original per Zufallszahl ermittelt werden. Das gilt für den Spieler SAP (wer=1) immer und für den Spieler USR (wer=5) wenn die Anzahl der Spieler Null ist (a=0). Vor dem setzen des Zuges, wird der Zug für den Spieler SAP strategisch gesprüft. Zunächst Defensiv – das heisst, hat der Spieler USR zwei Züge gemacht (ein Zug hat den Wert 5) ist die Summe der Zeilen, Spalten oder Diagonalen gleich 10. Ist sie gleich 10, bedeutet es, das der nächste Zug des Spielers USR zum Gewinn führt. Es wird also das freie Feld in der Zeile, Spalte oder Diagonalen gesucht und die Werte x und y, für den nächsten Zug des Spielers SAP, angepasst.
Danach erfolgt die Offensivprüfung. (Im Code sehen wir die Aufrufe PERFORM strategie USING 10. und PERFORM strategie USING 2.) Hier wird nun geprüft ob der nächste Zug des Spielers SAP zum Gewinn führt. Es ist sinnvoller direkt zu gewinnen, als sich zu verteidigen. Die Werte x und y können also wieder manipuliert werden. KÖNNEN! Wie gesagt, die Werte x und y sind Zufallszahlen und bleiben unverändert wenn keine Strategie greift. Das passiert solange keine zusammenhängende Züge gemacht werden, wie zum Beispiel zum Beginn des Spiels.
Genau hier liegt jetzt die Chance des Spielers USR. Nur noch mit Glück und ausgefeilter Taktik kann USR noch gewinnen. Zum Beispiel führen die Züge 2,1 3,3 2,2 mit dem finalen Schlag auf 2,3 zum Gewinn. WENN keine Zufallszahl in die Quere kommt. Das Geheimnis liegt darin, zwei mögliche Gewinnsituationen zu stellen. Mit 2,1 3,3 „bemerkt“ die Strategie noch nichts. Kommt jetzt 2,2 hinzu, habe ich in der zweiten Zeile und in der Diagonalen die Summe 10. Für den User SAP wird jetzt vorrangig ein Zug in der Diagonalen vorgeschlagen, also auf 1,1. Jetzt kann USR in der zweiten Zeile gewinnen.
Mit Defensivstrategie wird es für den User schwierig
Lang ist es her, aber gerne benutze ich den alten Code und lasse ihn auch noch auf einer PDP11 laufen. Im letzten Workshop sprachen wir über die Möglichkeiten der Programmierung eines Reports in ABAP. Wir wissen, das ein Report für die dynamische, interaktive Darstellung von Listen gedacht ist. Als Übung, damit die laufzeitabhängigen Ereignisse eines Reports klar werden, habe ich den original DEC Code des Spiels „Tic Tac Toe“ gegeben der analysiert und in ABAP realisiert werden sollte.
Hier nun eine kurze Vorstellung meiner Musterlösung.
Der Sinn des Spiels ist klar – drei Felder, in einer Reihe, Spalte oder Diagonalen sind zu besetzen. Wir erkennen im Original, in den Zeilen 1090 und folgenden, das die Züge der Maschine per Zufallszahl erzeugt werden.
Das ist auch so in ABAP realisierbar. Es stehen ein Funktionsbaustein aus der Gruppe QF05 (QF05_RANDOM_INTEGER) sowie die Klasse CL_ABAP_RANDOM_INT zur Verfügung.
Expliziet wird der Zug geprüft, nämlich ob das Feld bereits belegt wurde und ob der Zug zum Gewinn der Partie führt. Das Vorgehen, auch gerade mit den im Original verwendeten Befehlen GOTO und GOSUB, ist im Report nicht möglich da er nicht prozedual abläuft. Um nah, wie die Aufgabe lautet, am Original zu bleiben, empfiehlt sich für den Ersatz des GOSUB der Befehl PERFORM.
Um die Sache etwas interessanter zu machen, habe ich zwei Dinge berücksichtig. In der Grundliste des Reports (SY-LSIND = 0) kann „Anzahl Spieler 0“ eingegeben werden. Das Programm spielt dann beide Spieler – wir erinnern uns an den Klassiker „War Games“. Eine Defensivstrategie ermöglicht dem Spieler „SAP“ einen Gewinnzug des Gegners zu verhindern. Taktisch wird nach jedem Zug die Summe der Zeilen, Spalten und Diagonalen errechnet und dem entsprechend ein Zug vereinbart. Dennoch ist es dem User möglich zu gewinnen, nämlich dann, wenn es mehr als eine Gewinnmöglichkeit gibt. Eine Offensivstrategie ist nicht implementiert – das kann als
Ohne Defensivstrategie ist der User im Vorteil.
Zwei Gewinnmöglichkeiten. Der User hat die Chance zu gewinnen.
Mit Defensivstrategie wird es für den User schwierig
Zusatzaufgabe verstanden werden. Offensiv heisst, das Programm stellt nicht fest ob oder das der nächste Zug zum Gewinn führt. Gibt es nichts zu verteidigen, wird eine Zufallszahl über den nächsten Zug entscheiden!
Möglichkeiten, Daten aus Altsystemen in SAP zu importieren, gibt es reichlich. LSWM, SHDB sind die wichtigsten Transaktionen die auch sehr gut dokumentiert sind. Sie basieren auf der Technik des Batch-Input – also des „abspielens“, des simulierens einer Benutzeraktion mit Dateneingabe. Im Fall des Adressimports, genauer: Adressdatensätze der Geschäftspartner – ist dieses Vorgehen sehr umständlich, sehr Ressourcenaufwendig und führte, bei meinen Versuchen, zu einem Speicherüberlauf da nicht nur die BUP1 Transaktion angesprochen wird, sondern zeitgleich mehrere Prozesse angestossen werden die für die Sache eigentlich nicht nötig sind. Es sollte unbedingt darauf verzichtet werden und den Import über Code und den entsprechenden Verbucher-Funktionsbausteinen der BAS zu realisieren. Hilfreich ist diese Seite zu der Funktionsgruppe SZA1.
In der Schulung gehen wir einmal den Weg eines Batch-Inputs der grundsätzlich sehr gut ist.
In der Transaktion SHDB starten wir eine neue Aufzeichnung mit der Transakton BUP1 und legen einen Kunden „Mustermann“ an. Wenn die Aufzeichnung nach dem speichern des Kunden beendet ist, sieht man eine lange Liste der ausgeführten Aktionen auf dem Screen.
Mit dieser Aufzeichnung lässt sich einiges anstellen: Als Vorlage für den Import mit der Transaktion LSMW, als eigenständiger Report oder als Funktionsbaustein. Letzteren wollen wir einmal ausprobieren.
Hier zeigt sich schon der ernorme Ressourcenverbrauch. In meinem Beispiel importiere ich eine CSV Datei mit 4000 Sätzen. Es wird 4000 mal der Input in die Transaktion BUP1 erzeugt. Man sollte darüber kurz nachdenken, bevor man F8 drückt! In der Realität würde ich mit Sicherheit den Verbucherbaustein direkt mit einem COMMIT WORK AND WAIT aufrufen.
Datemimport ist eine einmalige Sache, bei der man schon den zu betreibenden Aufwand berücksichtigen muss. Über den Batch-Import ist aber immer gewährleistet, nur gültige Daten importiert zu haben. Andere Ideen, wie der Import in das BAS schöner gestaltet werden kann, sind willkommen und werden veröffentlicht!
Nach Aufzeichnung lassen sich automatisch Reports und Funktionsbausteine generieren.
Nach Aufbereitung der Importdaten, wird pro Satz einmal der FB aufgerufen
Entwickeln und lernen macht in der Gruppe mehr Spass. SAP stellt ein Basis-System für Entwicklungsarbeit kostenlos zur Verfügung von denen wir zwei Systeme in Betrieb halten. Zum einen ein Netwaeaver 702 auf einem Windows Terminalserver und ein Netweaver 750 System auf meinem Linux PC. Ein gravierender Unterschied fiel mir auf, den das System 702 zum idealen Entwicklungssystem für Gruppen kürt.
Neben den Änderungen der Syntax im ABAP Befehlssatz (Artikel) ist der Entwicklerschlüssel, der zur Erzeugung von Code im System berechtigt, nun digital signiert und setzt einen installierten Lizenzschlüssel voraus!
Wir wissen, bei der ersten Inbetriebnahme wird zunächst ein temporärer Lizenzschlüssel generiert, der sich bei der Berechnung der Gültigkeit zunächst an der Systemuhr zum Zeitpunkt des Starts orientiert. Im Netweaver 702 konnte es nun passieren, das man das System mit einem gültigen, sehr lange gültigen, temporären Lizenschlüssel in Betrieb nimmt und der Entwicklerschlüssel auch gültig ist.
Dieser Fehler, den man fairer Weise niemals nicht nie ausnutzen sollte, wurde in der Version 750 korrigiert – eben durch Signierung des Entwicklerschlüssels mit der signierten Programmlizenz, so das hier alle 90 Tage die Lizenz erneuert werden muss.
In beiden Versionen ist der Entwicklerschlüssel immer nur einmal gültig! Das heisst: Mag man auch so viele Benutzer und Mandanten anlegen können, wie man möchte, gibt es nur einen Entwickler. Ungünstig, wenn mit mehrer Entwicklern an einem Projekt gearbeitet werden soll.
Schalten wir doch vor Eingabe des Entwicklerschlüssels einmal den Debugger ein und verfolgen die Programmlogik. Wir sehen, dass ein Funktionsbaustein aus der Funktionsgruppe SKEY benutzt wird. Im ablaufenden Include Programm wird die Funktion
Implizite Erweiterung im Rahmenprogramm Include
NETWEAVER 702 und 750. Code ist gleich geblieben
„DEVELOPER_KEY_CHECK“ nach der Güligkeit des Schlüssels befragt, die mit entsprechenden Rückgabewert SY-SUBRC den Entwickler zulässt oder eben nicht. Hier können wir eine impliziten Erweiterung vornehmen, nämlich derart, das der Rückgabewert der Funktion immer „0“ also gültig ist. Beliebig viele Benutzer können nun mit dem einen gültigen Entwicklerschlüssel Code erzeugen.
In den neueren Spielereien unseren hochgeschätztem Enno Wulff wird der überarbeitete ABAP Befehlssatz verwendet. Ich verwende noch den Stand 702 und kann so einfach seinen Code nicht übernehmen.
So verwendet er gerne die neue Kurzschreibweise mit der eine Klasse instanziiert wird: NEW x( ).
Seht in seinen Code unter den Zeilen 20 und 98 und erinnern wir uns an BC401 Seite 59.
Die Zeile 20 mit „timer = NEW #( )“ ändern wir durch –> „CREATE OBJECT timer.“ und das „NEW main()–>start().“ ersetzen wir mit
„DATA m TYPE REF TO main.
CREATE OBJECT m.
m->start( ).“
Dann läuft die Sache auch und ist eine tolle Vorlage für so manch Lösung.
Sehr praktisch im täglichen Umgang sind kalkulierende, also selbst rechnende Felder. Will man zB. im Buchungsvorgang Skonto für Teilbeträge buchen, kann die Rechenoperation einfach in das Soll/Haben Feld eingetragen werden. Das ist im Microsoft Dynamics NAV in jedem numerischen Feld vorgesehen – es wird nach der „Punkt vor Strich“ Regel gerechnet. In der Praxis ist das nicht immer gewollt.
Der Chef legt zum Beispiel eine Tankquittung vor auf der auch neben dem abzugsfähigen Treibstoff und einer Dose Öl auch Zigarretten und ein Lolli für das Kind aufgeführt ist. Praktischer Weise rechnen wir 10 Euro plus 5 Euro mal 19% und nicht (10+5)*19/100. Im NAVISION bleibt keine Wahl, das Verfahren ist nicht änderbar. Es funktioniert nur Punkt-vor-Strich.
In unserem SAP System sind die Möglichkeiten offen. Als Demo habe ich einmal alle Möglichkeiten aufgeführte.
Dynamics NAV – alle numerischen Felder sind selbst rechnend
In der Praxis ist die Punkt vor Strich Regel nicht von Vorteil
das gewollte Ergebnis durch sequenzielle Rechnung
Mit „Punkt vor Strich“ Rechnung kommt man in diesem Beispiel zum falschen Ergebnis
Der SAP Taschenrechner rechnet auch sequenziell und überträgt das Ergebnis in die Eingabemaske
Der Standard Funktionsbaustein ‚EVAL_FORMULA‘ ist in der Lage ein String mit „10+5*0,19“ zu verarbeiten und nach der PvS Regel zu berechnen. Es ist also keine Schwierigkeit in einem PAI das Eingabefeld durch diesen Funktionsbaustein verarbeiten zu lassen und das selbt rechnende Feld ist realisiert.
Ich persönlich halte das für unpraktisch. Ähnlich wie der SAP Calculator, den wir mit dem Funktionsbaustein ‚FITRV_CALCULATOR‘ aufrufen können, läßt sich auch der Eingabestring zerlegen und sequenziell verarbeiten.
Wie in dem Listing zu sehen ist, zerlege ich den Eingabestring in eine Interne Tabelle. Die Zeichen + – * / separieren die Zahlen und rechnen entsprechend der Operation sequenziell.
Sequenzielle Berechnung eines Strings
Letztendlich mag es eine Sache der Gewöhnung sein. Mich interessieren die Erfahrungen die andere gemacht haben.
Die SAP-Integration von agorum® core verbindet Ihr Dokumentenmanagement-System über den SAP ArchiveLink nahtlos mit Ihren Anwendungen in SAP. So nutzen Sie alle Vorteile eines systemübergreifenden Dokumentenmanagements.
Nach dem wir ein SAP Basis System nun vollständig installiert und mit einigen Grunddaten befüllt haben, geht es an ein paar Fingerübungen. Das derzeitige Entwicklerteam besteht übrigens aus drei Personen, in Deutschland verteilt und arbeitet an einem Terminalserver der GfUD an der Realisierung des Projekts. Ziel ist es, einige Übungen, Tipps und Tricks rund um das „miniSAP“, dem SAP Netweaver Basissystem, zu erarbeiten. Wenn sich jemand dafür interessiert und mitmachen möchte, kann sich melden.
In unserer ersten Transaktion werden die gewählten Adressen, also der Empfänger und der Absender eines Dokumentes ausgewählt und abgeglichen. Der Absender ergibt sich aus dem Userstamm. In den Transaktionen SU01 sowie SUCOMP ist der Benutzer sowie die Firma, für die der User fakturiert, hinterlegt.
Die Transaktionen BUP1, BUP2, BUP3 dienen uns zum anlegen, ändern und anzeigen der Geschäftspartner.
Uebersicht GfUD Faktura
Einstiegs DynPro
Während die Daten des Geschäftspartners vollständig vorliegen (Steuernummer, Bankdaten) müssen wir für die hinterlegte User bezogene Firma, eine weitere Tabelle anlegen. Auch muss im Hinblick auf eine gesetzkonforme Archivierung an die Speicherung der Daten gedacht werden. Das heisst: Adress- und steuerrelevante Daten können sich ändern. Ein angelegter Beleg soll aber, unabhängig von der Archivierung des SAP SmartForms, vom System reproduzierbar sein. Adressänderungen werden im BAS durch Änderungsbelege dokumentiert, weshalb wir die zusätzliche Speicherung in Frage stellen können.
Grundsätzlich ist der Umgang sehr einfach. Der Umgang mit Userdaten, externer Adressen und Geschäftspartnern ist durch zahlreiche Funktionsbausteine vorbereitet.
Von der Transaktion BUP3 (Anzeige Geschäftspartner) aus, wird die Partnernummer des Geschäftspartners über einen SET/GET Parameter transportiert. Den greifen wir auf
GET PARAMETER ID 'BPA' FIELD partner.
Um jetzt von der Partnernummer aus, Adressen aus zu lesen, müssen einige Tabellen befragt werden. Wenn die Daten vorhanden sind, liefer der Funktionsbaustein BUA_ADDRESS_GET_ALL einen Geschäftspartner Adresssatz als interne Tabelle.
SELECT addrnumber INTO adrnum FROM but020 WHERE partner = partner.
ENDSELECT.
SELECT * FROM adrp INTO it_person WHERE persnumber = ( SELECT persnumber FROM adcp WHERE addrnumber = adrnum ).
ENDSELECT.
CALL FUNCTION 'BUA_ADDRESS_GET_ALL'
EXPORTING
i_partner = partner
TABLES
* T_ADDRNUMBER_GUID =
t_address = it_adr
Die Userdaten und die hinterlegte Firmenadresse sind teilweise auch im BAS gespeichert und können über den Funktionsbaustein ADDR_GET abgerufen werden.
SELECT addrnumber FROM usr21 INTO selektion-addrnumber WHERE bname = username.
ENDSELECT.
SELECT name_text from v_usr_name INTO name where bname = username.
ENDSELECT.
CALL FUNCTION 'ADDR_GET'
EXPORTING
address_selection = selektion
IMPORTING
ADDRESS_VALUE = adresse
Symbole zu Standardgrussformeln kann man in der Transaktion SE75 (Symbolnamen) oder mit der SE16 in der Tabelle TTDTG (maximale Trefferzahl nicht begrenzen) finden.
SE75TTDTGD
Schön ist auch die eigene Zeitzone WDFT – die Walldorfzeit.
damit die laufzeitabhängigen Ereignisse eines Reports klar werden, habe ich den 
im Original, in den Zeilen 1090 und folgenden, das die Züge der Maschine per Zufallszahl erzeugt werden.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.