Offene Stelle

• Junior-Softwareentwickler Baan

Offene Stellen

• Baan-Admin/Entwickler in Rheinland-Pfalz, LN-Kunde

• ERP-LN Projektmanager bei Infor
  

Infor auf der Systems

Die Cebit wird von Infor ja inzwischen geflissentlich ignoriert, auf der Systems sind sie jetzt zu finden, Stand 227B, Halle A1, vom 21. bis 24. Oktober 2008

• Infor ERP COM
• Infor ERP Xpert
• Infor ERP LN

sind wohl die (ERP-)Produktlinien, die zu sehen sein werden. Wer mit Infor einen Termin vereinbart, kriegt die Eintrittskarte umasunst.

ERP LN-Abschluss in Südafrika

Eine Tochter der BAE in Südafrika hat sich für ERP LN entschieden. Eigentlich wär's mir ja lieber, man würde mit dieser Software was anderes als Waffen bauen.

Nicht tun, bitte: Nummer 1) Nicht kommentieren

Man sollte es nicht glauben, aber das ist noch immer die häufigste und schlimmste Sünde. Schon bei der Eigenentwicklung von Komponenten, noch schlimmer bei der Anpassung von Standardkomponenten. Da könnte Lagnese glatt ein achtes Todsündeneis erfinden.

Grundsätzlich gilt bei der Anpassung von Standardkomponenten: Es wird kein Code gelöscht, sondern nur auskommentiert. Jedes eingefügte Codesegment wird als solches gekennzeichnet.

Oben im Kopf des Programmskriptes wird unterhalb der Standardkommentare angegeben, dass man eine Änderung vorgenommen hat, wann das war, was man gemacht hat, und warum. Für diese Änderung wird ein bestimmtes Kürzel angeben, mit dem die Änderungen im Programmskript gekennzeichnet sind. Für die nächste Änderung (sei es, aufgrund neuer Anforderungen, oder weil man zwei Tage später noch einen Fehler gefunden hat, wird ein neuer Kommentar im Kopf eröffnet und ein neues Kürzel vergeben.

Wie diese Kürzel auszusehen haben, dafür hat sich leider noch keine Konvention durchgesetzt. Infor nutzt hier Solution- oder Businessrequestnummern. Hat die eigene EDV ein ähnliches Prinzip, dass jede Softwareänderung in Bezug auf einen Eintrag in einem Change-Managementsystem stehen muss, kann man es ähnlich halten. Vorausgesetzt, man kann da tatsächlich mehrere Nummern generieren, wenn man mehrfach wegen einer Anforderung eine Source ändert. Ich persönlich bevorzuge es, für diesen Zweck meine Initialen und eine dreistellige Zählnummer zu nutzen (also: UF001, UF002, UF003 etc.) Nicht sehr praktikabel dagegen finde ich die Methode, mit Initialien und Datum zu arbeiten (UF080813), das wird zu lang, und bei zwei Änderungen an einem Tag hat man ein Problem.

Wofür es aber eine Konvention gibt, ist die Art, wie man dieses Kürzel zum Markieren seiner Änderungen im Skript benutzt. Diese Konvention wurde seinerzeit unter Baan eingeführt, wird bis heute zur Markierung von Änderungen aufgrund Solutions genutzt und sollte eigentlich allgemeiner Standard sein. Leider halten sich nicht alle dran, darum hier mal in aller Ausführlichkeit: Gesetzt den Fall, wir haben für unsere Änderung das Kürzel UF001 definiert. Dann kennzeichnet:

• UF001.o eine herausgelöschte, (das heißt auskommentierte!) Proogrammzeile. Das o steht für "out".
• UF001.n eine neue Programmzeile. Ein n für "new" also
• UF001.so den Beginn einer größeren Anzahl von Zeilen, die man herausgenommen hat (so für "start out")
• UF001.eo das Ende eines solchen Blocks (end out)
• UF001.sn den Beginn einer größeren Anzahl von Zeilen, die man eingefügt hat (sn für "start new")
• UF001.en das Ende eines solchen Blocks (end out)

Als Faustregel gilt, dass mehr als zwei eingefügte oder gelöschte Zeilen mit so/eo und sn/en markiert werden. Unlesbar werden Programme, wenn jede einzelne neue Codezeile mit einem solchen Marker versehen wird.

Möchte man also in folgendem Code...

|*
|* This would be the last part of the Infor standard comment
|* section on top of the script
|*
|*************************************************************

...
   select  tcibd001.*
   from    tcibd001
   where   tcibd001._index1 inrange {:item.f} and {:item.t}
   and     tcibd001.csel >= {:csel.f}
   and     tcibd001.csel <= {:csel.t}
   and     tcibd001.citg >= {:citg.f}
   and     tcibd001.citg <= {:citg.t}
   order   by tcibd001._index1
   selectdo
           call.a.funny.method (tcibd001.item)
   endselect

die Selektion ändern und den Funktionaufruf durch einen andere Funktion ersetzen, so modifiziert man das bestehende Programm wie folgt:

|*
|* This would be the last part of the Infor standard comment
|* section on top of the script
|*

|*************************************************************
|*
|* UF001 - 2008-08-13,
|* Ulrich Fuchs, Büro für Informationsarchitekturen, mail@ulrich-fuchs.de
|*             * Zusätzliche Artikelselektion statt über Selektionscode
|*               und Artikelgruppe über Signalcode
|*             * eine andere Lustige Funktion gerufen
|*
|*************************************************************

...
    select  tcibd001.*
    from    tcibd001
    where   tcibd001._index1 inrange {:item.f} and {:item.t}
|UF001.so
|      and     tcibd001.csel >= {:csel.f}
|      and     tcibd001.csel <= {:csel.t}
|      and     tcibd001.citg >= {:citg.f}
|      and     tcibd001.citg <= {:citg.t}
|UF001.so
|UF001.sn
       and     tcibd001.csig >= {:csig.f}
    and     tcibd001.csig <= {:csig.t}
|UF001.en
       order   by tcibd001._index1
    selectdo
|                call.a.funny.method (tcibd001.item)                  | UF001.o
                 call.another.funny.method (tcibd001.item)            | UF001.n
        endselect

Keinesfalls aber sollte man also geänderte Zeilen finden, bei denen weder klar ist, was vorher da stand, noch was geändert wurde. Mancher Programmierer und dito manche -in greift in obiger Situation schon mal zu

...
    selectdo
              call.another.funny.method (tcibd001.item)  | UF001
       endselect

Das ist böse, gemein, unwartbar. Nicht tun, bitte.

Nicht tun, bitte

Eines der häufigsten Argumente, warum man Baan-Software nicht anpassen soll, ist, dass die Anpassungen ja so schlecht wartbar seien und es immer so aufwändig sei, diese auf neue Solutionstände zu migrieren. Mittlerweile glaubt das sogar Infor.

Es stimmt einfach nicht.

Wenn Anpassungen schwer zu migrieren sind, dann liegt es in der Regel daran, dass sie schlecht spezifiziert und leider meist noch schlechter programmiert sind.

Ich werde mal versuchen, die häufigsten Programmierfehler (aus meiner Sicht) aufzulisten, die mir in diversen Anpassungen auf diversen Baan-Systemen begegnen, mit denen ich so zu tun kriege. Nicht, um mit dem Finger auf jemand zu zeigen (Namen werden eh keine genannt), sondern damit gerade Programmierneulinge in den Baan-Tools nicht nur von schlechten Beispielen lernen.

Jeder "Fehlertyp" (englisch heißt sowas "Pitfall") kriegt ein eigenes Posting, hier führe ich das ganze dann immer zusammen.

Nun denn:

#1 - Nicht kommentieren
#2 - Globale Variablen, ohne dass das sein muss
#3 - Nichtssagende Variablennamen

Finanzierung von Infor-Installationen über IBM

Trading Markets berichtet, dass Infor mit IBM eine Partnerschaft eingegangen ist, mit deren Hilfe Infor-Kunden über die IBM Global Financing entsprechende Installationen finanzieren können.