Ja ich weiß, heute ist Sonntag. Aber ich arbeite auch nicht. Trotzdem: Wer hätte gedacht, dass es unser Jan und Paul noch so weit bringen würden, zu mythischen Figuren zu werden, über die man Filme dreht?
Nun ist De uitverkorene (Die Auserkorenen) schon zwei Jahre alt, und ich hab's jetzt erst mitgekriegt.
Die Handlung und die Personen sind frei erfunden... Oder so...
Sonntag, 22. Juni 2008
Mittwoch, 18. Juni 2008
User Exits jetzt verfügbar
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
Im Skript kann man dann bis zu acht Funktionen definieren, deren Namen schonmal zu Hirnverknotung führen können:
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?
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.
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.
Montag, 16. Juni 2008
Bauchladenschaufenster
Der Infor-Seite http://www.infor.com kann man ja leider nicht so richtig entnehmen, was sich Infor so alles zusammengekauft hat. Schön übersichtlich aufbereitet hat das ganze das Enterprise Software Directory hier.
Samstag, 14. Juni 2008
Wozu Testfirmen gut sein können
Testfirmen sind nicht zu unterschätzen. Nicht nur zum Testen, auch als Backup. Geben wir's zu: Jeder, der aus irgendwelchen Gründen Massenupdates auf einem Produktivsystem fahren muss, zerschießt mal Daten.
Ein Kunde wollte global Arbeitspläne aktualisieren. Durch einen dummen Fehler waren auf einmal in über 15000 Arbeitsgangzeilen die Vorgabezeiten futsch. Mindestens vier Leute, mich eingeschlossen, haben alle zusammen ein bisschen gepennt und eine Nebenwirkung eines dafür leicht angepassten Standardprogramms im Zusammenspiel mit der Art, wie die Stammdaten beim Kunden eingerichtet sind, einfach übersehen. Getestet haben wir das Updateprogramm dann auch noch ausgerechnet mit Daten, bei denen das Problem systembedingt nicht auftrat. Wie in solchen Fällen üblich, addierten sich also eine Menge kleinerer Unaufmerksamkeiten zum Unfall. Sollte nicht passieren, ist aber passiert. Gemerkt hat man das drei Tage später - zu spät, um die Tabelle aus einem Backup zurück zu laden, weil inzwischen ja neue Arbeitspläne angefallen sind.
Die Testfirma war zwar sechs Wochen alt, aber dort ließen sich die Zeiten für die benötigten Arbeitsgangzeilen rausladen und neu ins Echtsystem einspielen. Es blieben zwar dreißig Sätze übrig, die man noch händisch ankucken musste, aber dank Testfirma hat sich das Malheur nicht zur Katastrophe entwickelt.
Ein Kunde wollte global Arbeitspläne aktualisieren. Durch einen dummen Fehler waren auf einmal in über 15000 Arbeitsgangzeilen die Vorgabezeiten futsch. Mindestens vier Leute, mich eingeschlossen, haben alle zusammen ein bisschen gepennt und eine Nebenwirkung eines dafür leicht angepassten Standardprogramms im Zusammenspiel mit der Art, wie die Stammdaten beim Kunden eingerichtet sind, einfach übersehen. Getestet haben wir das Updateprogramm dann auch noch ausgerechnet mit Daten, bei denen das Problem systembedingt nicht auftrat. Wie in solchen Fällen üblich, addierten sich also eine Menge kleinerer Unaufmerksamkeiten zum Unfall. Sollte nicht passieren, ist aber passiert. Gemerkt hat man das drei Tage später - zu spät, um die Tabelle aus einem Backup zurück zu laden, weil inzwischen ja neue Arbeitspläne angefallen sind.
Die Testfirma war zwar sechs Wochen alt, aber dort ließen sich die Zeiten für die benötigten Arbeitsgangzeilen rausladen und neu ins Echtsystem einspielen. Es blieben zwar dreißig Sätze übrig, die man noch händisch ankucken musste, aber dank Testfirma hat sich das Malheur nicht zur Katastrophe entwickelt.
Donnerstag, 12. Juni 2008
BIRT
Ein Interview mit dem Chefevangelisten von BIRT, das ja bekanntlich die neue Report-Engine von Baan werden soll (allerdings eben nicht nur mit Baan genutzt werden kann, sondern ein generell nutzbares Reporting-Framework ist):
http://eclipse.dzone.com/news/birt-a-technical-interview-wit
Nebst ein paar Hinweisen über aktuelle Bücher zum Thema und Anlaufstellen, wenn man nicht weiter kommt.
http://eclipse.dzone.com/news/birt-a-technical-interview-witNebst ein paar Hinweisen über aktuelle Bücher zum Thema und Anlaufstellen, wenn man nicht weiter kommt.
Aachener ERP-Tage
Infor lässt die Cebit ja aus unverständlichen Gründen schon einige Zeit links liegen, auf den Aachener ERP-Tagen (Auch da heißt Raider jetzt Twix, früher warn's die Aachener PPS-Tage) sind sie aber noch zu finden, Stand 19 vom 17. Juni bis 19. Juni, Eurocongress Aachen:
http://www.infor.de/content/1656547/?cid=WW-ALL-0807-Alle-GOOGLE-WENS1
http://www.infor.de/content/1656547/?cid=WW-ALL-0807-Alle-GOOGLE-WENS1
Dienstag, 10. Juni 2008
ERP-Redesign von unten?
Ein Maschinenbauer setzt Baan IV seit 1996 ein. Wir kennen das alle: Nach zehn Jahren knirscht es an allen Ecken und Enden, und man fragt sich, was man tun soll. Die Firma hat die Frage mit Hilfe des Münchner Instituts für Sozialforschung (IFS) zu beantworten versucht - Frau Pfeiffer vom IFS und Kollegen haben mit gemischten Teams aus den armen Menschen der Produktion, die mit der Software arbeiten sollen, und den armen Menschen, die in der IT für die Software zuständig sind, Verbesserungsvorschläge erarbeiten lassen. Von 2005 bis 2007.
Was ist rausgekommen dabei? Zunächst einmal dieser Aufsatz hier:
http://www.sabine-pfeiffer.de/downloads/2008-WBU-Beitrag.pdf,
eine Webseite
http://www.integrunt.de/informatisierung/index.htm
und dann ein Buch, das ich hoffentlich demnächst mal auf den Tisch bekomme:
Sabine Pfeiffer, Tobias Ritter, Eric Treske: Work Based Usability. Produktionsmitarbeiter gestalten ERP-Systeme „von unten“ – Eine Handreichung
Und sonst? Die Analyse im Aufsatz gibt die typische Ausgangsbasis wieder: "Die Änderungsdynamik von Unternehmen verlangt in solchen Zeiträumen oft mehrfachen Wandel, bis in ihre Organisationsstrukturen und bis in einzelne
Geschäftsprozesse hinein. Wandlungsprozesse, die oft auf der Ebene der ERP-Systeme nicht in Gänze nachvollziehbar sind"
Nur wie schafft man Abhilfe?
Dem Aufsatz entnehme ich, dass vier "besonders dringliche Probleme" herausgefunden wurden: "Der Einsatz eines Handscanners im Lager; ein konsistenter Umgang mit disponiblen Teilen; die zeitnahe Aktualisierung bei Bestandslisten bei neu eingegangenen Teilen ohne zugewiesenen Lagerplatz sowie das Abspecken der Masken im Einkauf."
Da frage ich mich schon, warum man da fast zwei Jahre Projektarbeit braucht, um einen Scanner als sinnvoll zu beschreiben, um festzustellen, dass die Disposition hakelt? Was bitte ist die "zeitnahe Aktualisierung bei Bestandslisten bei neu eingegangenen Teilen ohne zugewiesenen Lagerplatz"? Die Liste ist doch wohl nicht das Problem, sondern der Prozess der Wareneingangsbuchung? Naja, und das Abspecken der Masken im Einkauf ist wahrscheinlich eine Fingerübung für die IT Abteilung.
Und wenn Frau Pfeiffer dann schreibt: "In den letzten Jahren kommt zudem die schrittweise Umstellung von Baan auf WinBaan hinzu" - dann frage ich mich schon, was sie vom ERP-System wirklich mitbekommen hat? WinBaan? Sie meint wohl die bw, aber wo ist das Problem, wenn die IT die Anwender überzeugt bekommt, sich mal von der ASCII-Oberfläche zu verabschieden? Die mag ja bei manchem User ungeliebt sein, aber ein Prozess, "der zusätzlich die Kapazitäten der IT bindet"?
Was leider mit keinem Wort erwähnt wird: Konnte man irgend etwas von den Verbesserungsvorschlägen umsetzen? Oder passierte genau das, was die Analyse schon sagte: Man weiß, dass es nicht mehr richtig passt, nur ändern kann man es halt nicht. (Kleiner Tip: Richtiges Projekt aufsetzen, nach ERP LN migrieren, und die Probleme kommen vom Tisch).
Vielleicht statt Soziologen doch lieber IT-Experten für solche Projekte anheuern? Ich werde mal das Buch abwarten...
Was ist rausgekommen dabei? Zunächst einmal dieser Aufsatz hier:
http://www.sabine-pfeiffer.de/downloads/2008-WBU-Beitrag.pdf,
eine Webseite
http://www.integrunt.de/informatisierung/index.htm
und dann ein Buch, das ich hoffentlich demnächst mal auf den Tisch bekomme:
Sabine Pfeiffer, Tobias Ritter, Eric Treske: Work Based Usability. Produktionsmitarbeiter gestalten ERP-Systeme „von unten“ – Eine Handreichung
Und sonst? Die Analyse im Aufsatz gibt die typische Ausgangsbasis wieder: "Die Änderungsdynamik von Unternehmen verlangt in solchen Zeiträumen oft mehrfachen Wandel, bis in ihre Organisationsstrukturen und bis in einzelne
Geschäftsprozesse hinein. Wandlungsprozesse, die oft auf der Ebene der ERP-Systeme nicht in Gänze nachvollziehbar sind"
Nur wie schafft man Abhilfe?
Dem Aufsatz entnehme ich, dass vier "besonders dringliche Probleme" herausgefunden wurden: "Der Einsatz eines Handscanners im Lager; ein konsistenter Umgang mit disponiblen Teilen; die zeitnahe Aktualisierung bei Bestandslisten bei neu eingegangenen Teilen ohne zugewiesenen Lagerplatz sowie das Abspecken der Masken im Einkauf."
Da frage ich mich schon, warum man da fast zwei Jahre Projektarbeit braucht, um einen Scanner als sinnvoll zu beschreiben, um festzustellen, dass die Disposition hakelt? Was bitte ist die "zeitnahe Aktualisierung bei Bestandslisten bei neu eingegangenen Teilen ohne zugewiesenen Lagerplatz"? Die Liste ist doch wohl nicht das Problem, sondern der Prozess der Wareneingangsbuchung? Naja, und das Abspecken der Masken im Einkauf ist wahrscheinlich eine Fingerübung für die IT Abteilung.
Und wenn Frau Pfeiffer dann schreibt: "In den letzten Jahren kommt zudem die schrittweise Umstellung von Baan auf WinBaan hinzu" - dann frage ich mich schon, was sie vom ERP-System wirklich mitbekommen hat? WinBaan? Sie meint wohl die bw, aber wo ist das Problem, wenn die IT die Anwender überzeugt bekommt, sich mal von der ASCII-Oberfläche zu verabschieden? Die mag ja bei manchem User ungeliebt sein, aber ein Prozess, "der zusätzlich die Kapazitäten der IT bindet"?
Was leider mit keinem Wort erwähnt wird: Konnte man irgend etwas von den Verbesserungsvorschlägen umsetzen? Oder passierte genau das, was die Analyse schon sagte: Man weiß, dass es nicht mehr richtig passt, nur ändern kann man es halt nicht. (Kleiner Tip: Richtiges Projekt aufsetzen, nach ERP LN migrieren, und die Probleme kommen vom Tisch).
Vielleicht statt Soziologen doch lieber IT-Experten für solche Projekte anheuern? Ich werde mal das Buch abwarten...
Abonnieren
Posts (Atom)
Posts
