Sie sind ja schon Helden der Kommunikation, unsere Inforianer (zumindest die Jungs und Mädels von der Baan-Schiene). Heimlich still und leise haben sie die schönste Neuerung seit den "secondary main tables" (was bitte? Ich weiß, die kennt auch noch keiner. Ich komm drauf zurück....) - die schönste Neuerung seit den "secondary main tables" also, in die Systemschicht geschmuggelt. Und keinem was gesagt.
Die Neuerung heißt "User-Exit", und hat nichts damit zu tun, was mancher Helpdeskmensch manchem Anwender wünscht.
User-Exists sind Ausgänge für Anwender im Sinne eines Baan einsetzenden Unternehmens. Sie bieten die Möglichkeit, eigenen Programmcode an bestimmte Ereignisse im normalen CRUD-(Create-Read-Update-Delete)-Ablauf einer Session dranzuhängen. Und zwar, das ist der Gag dabei,
ohne Standardskripte anpassen zu müssen. Also so ziemlich die Funktionalität, auf die man in der Baan-Entwicklung schon seit 1975 (oder so) wartet.
Das ganze funktioniert allerdings nur unter ERP LN. Soweit ich rausgekriegt habe, ist die Tools-Version (nicht das Porting-Set, nicht der Featurepack, nicht die Tools-Interface-Version) ausschlaggebend. Ist die Tools-Version 7.6.b4 installiert, sind die User-Exits lauffähig. Für die Tools-Version 7.6.a4 brauchts wohl die Solution 224004.
Mit dem User-Exit kann man Programmcode schreiben, der immer dann aufgerufen wird, wenn Datensätze in eine Tabelle eingefügt werden, geändert werden oder gelöscht werden. Vorausgesetzt, die Programme, die das tun, nutzen die DAL-Methoden (dal.save etc.), oder eine solche Änderung passiert auf der Maintable einer normalen Session.
Das ganze hört sich sehr nach DAL an und funktioniert auch ähnlich. Der Trick ist die Namenskonvention. Man definiert ein Programmskript, das genauso heißt wie die Tabelle, für die es gelten soll, hängt aber die Buchstaben "ue" für User-Exit hinten dran. Also: Das User-Exit-Skript für den Artikelstamm heißt tcibd001ue.
Beim Einfügen eines neuen UE-Skripts ist das System so clever, den Typ automatisch auf "Bibliothek" (DLL) zu stellen und ein Rumpfprogramm zu erzeugen.
Oben im Skript einzufügen ist ein
#include <bic_dam>Im Skript kann man dann bis zu acht Funktionen definieren, deren Namen schonmal zu Hirnverknotung führen können:
- ue.before.before.save.object([long mode])
- ue.after.before.save.object([long mode])
- ue.before.after.save.object([long mode])
- ue.after.after.save.object([long mode])
- ue.before.before.destroy.object()
- ue.after.before.destroy.object()
- ue.before.after.destroy.object()
- ue.after.after.destroy.object()
Diese werden, sofern vorhanden, jeweils vor bzw. nach der enstprechenden Funktion des DALs aufgerufen (ue.after.before.save.object () also bspw.,
nachdem die Funktion before.save.object() des DALs gerufen wurde). Und in diesen Funktionen hat man dann die ganze Bandbreite zur Verfügung wie im DAL, soll heißen, alle Felder der entsprechenden Tabelle sind hübsch gefüllt; with.old.object.values.do(...) und with.object.set.do (...) funktionieren, etc. Gibt eine Funktion 0 zurück, ist alles prima gelaufen, will man die Aktion abbrechen, kann man wie üblich mit dal.set.error.message (...) eine Meldung setzen und den Fehler mit dem Rückgabewert DALHOOKERROR den Call-Stack nach unten durchreichen.
Bevor man also als LN-Anwender überlegt, das xte DAL aufzubohren oder die xte Session anzupassen, um die üblichen Anforderungen ("wer hat diesen Datensatz wann geändert" etc.) zu erfüllen, sollte man ein Update von Tools und ggf. Portingset schonmal in Betracht ziehen. Die User-Exits erlauben zwar ein Einklinken nur auf Datensatzebene (für zusätzliche Feld-Checks etc. muss man immer noch das DAL der Tabelle aufbohren), aber das hilft häufig schon weiter.
Kleines Beispiel gefällig?
|******************************************************************************
|* tcibd001ue
|* User Exit Item Data
|******************************************************************************
#include <bic_dal>
table ttcibd001
table txyzus001
function extern long ue.after.after.save.object(long mode)
{
| Zum Beispiel: Bei Neuanlage oder Änderung User in Tabelle xyzus001 abstellen
on case mode
case DAL_NEW:
xyzus001.item = tcibd001.item
xyzus001.logn = logname$
db.insert (txyzus001, db.retry)
break
case DAL_UPDATE:
select xyzus001.*
from xyzus001 for update
where xyzus001._index1 = {:tcibd00._item}
selectdo
xyzus001.logn= logname$
db.update (txyzus001, db.retry)
endselect
endcase
return(0)
}
Letzter Tip: Damit User-Exits für die Tabelle tfacr200 möglich werden, braucht's die Solution 229257 nebst einer dort beschriebenen Parametrierung in tcmcs095 (weil die Standardskripte sonst offenbar "dumme" db.inserts machen). Vermutlich haben anderen Tabellen ähnliche Probleme, also nicht wundern, wenn's noch hakelt. Die Developer von Infor zaubern in letzter Zeit ein bisschen, aber auch Zaubereien schüttelt man nicht aus dem Ärmel.
Posts
