Externe Daten in die EPlan Artikeldatenbank einschleusen

Problemstellung

Es existieren sicherlich in einigen Unternehmen und Betrieben Listen mit speziell gepflegten eigenschaften. Das macht auch durchaus Sinn, Beispielsweise um den Typenschlüssel bestimmter Hersteller per VBA in Excel zu dekodieren. Wie bei allen Automationen: Das kann der Rechner schneller, akkurater und mit Beachtung aller Sonderfälle. Doch dann liegen die Infos in einer Exceltabelle und manuelles CopyPaste ist alles andere als Smart. Wie also überführen?

Problemlösung

Nun gibt es verschiedene Ansätze, wie die Daten nun von der Quelle in das Ziel gelangen.

• Transfer per *.csv : Die Daten gesammelt als *.csv abspeichern und in EPlan importieren. Das geht manuell als auch per Script. Problem nur an der Sache : Benutzerdefinierte Eigenschaften sind nach meinem Stand ausgenommen und auch einige andere Eigenschaften sind nicht zwingend erreichbar. Zudem: Felder können nicht ausgenommen werden, also Feld leer -> Eintrag wird gelöscht.
• Transfer per „Daten exportieren“ : Neu in 2022 dazu gekommen, ist das externe bearbeiten von Daten aus der Artikelverwaltung heraus. Her der Ansatz : Alle betroffenen Artikel exportieren, via Formel die Daten aus der Quelltabelle mit den Artikelnummern aus der Zieltabelle verknüpfen und wieder einlesen. Allerdings leider nur manuell machbar und damit zu aufwändig.
• Transfer per *.xml : XML oder auch Extensible Markup Language nutzt EPlan selbst, wenn alle Daten aus der Datenbank, aber nicht die Stammdaten dazu transportiert werden sollen (zum Beispiel beim Dataportal, Backup der Datenbank, …). Und schaut man sich mal einen Artikel an, ist das gar nicht so kompliziert. Daher betrachte ich diese Lösung im weiteren
• Transfer per *.edz : EPlans ureigenes Datenformat für Artikel nach zubauen wäre auch eine Möglichkeit. Und sicherlich wird das auch klappen. Ich denke nicht, dass EPlan da so schnell was raus streicht, eher erweitert. Bisher konnte ich allerdings keine Dokumentation dazu finden, wie das aufgebaut ist, daher bin ich da eher vorsichtig

Die Entscheidung fiel bei mir auf XML und damit bietet sich immer als erstes mal ein Artikel aus der Datenbank von EPlan mit bekannten Daten zu exportieren. Mit diesem ersten Export lässt sich die Struktur auswerten und schauen, was man alles braucht und was eben auch nicht. Wichtig bei XML sind die Tags, die immer einen Gegenpart haben, wenn diese nicht gleich wieder geschlossen werden:

<artikel>
  <attribut/>
</artikel>

In diesem Beispiel ist der Artikel ist eine Hülle in der die Attribute eingebettet sind. Eigenschaften können in den Tags stehen, oder von diesen eingeklammert sein. Schaut man sich so ein EPlan Artikel dann genauer an, sind einige Felder eher nettes Beiwerk und können raus. Die externe Quelle soll vielleicht nur kaufmännische oder detaillierte Daten ergänzen und bestimmte Felder nicht überschreiben. Daher macht es Sinn nach dem ersten „cleanup“ erst mal eine XML-Datei händisch zu füllen und den Umfang der Daten/den Import zu testen (wurde vielleicht zu viel heraus geschnitten). Es funktioniert alles wie gewollt? Perfekt, dann gleich weiter. Es kommen Fehlermeldungen oder Daten erscheinen nicht da, wo sie Sollen? dann nochmal zurück in den ersten Export, Open/Close-Tags prüfen, Aufbau prüfen, …
Manuell klappt es, dann geht es im nächsten Schritt, das automatisierte generieren der XML-Datei. Auch hier gibt es wieder einige Möglichkeiten die wohl einfachste: (neue) Textdatei öffnen und dann den Inhalt als Plain txt rein schreiben. Wer sich nicht mit „komplexem“ Aufbau von Knoten, Eigenschaften und Inhalten auseinandersetzen mag, oder wo es die Programmiersprache schlicht nicht her gibt, kann genau das machen, hier mal in VBA für Excel. Der Import läuft über die Action partlist, die Befehle für die Kommandozeile sind auch in der Hilfe zu finden.

public sub import()
  Dim FSO As Object
  Dim file As Object
  Dim filename As String
  Dim cmdstr As String
  
  ' Dateiname mit absoluten Pfad definieren und Öffnen
  filename = "C:/.../output.xml"
  Set FSO  = CreateObject("Scripting.FilesystemObject)
  Set file = FSO.opentextfile(filename, 2, True, -1)
  ' erste Zeile reinschreiben, doppeltes " maskiert das als Zeichen des Strings
  file.writeline ("<?xml version""1.0"" encoding=""utf-16"" ?>"
  file.writeline ("<partsmanagement type=""EPLAN.PartsManagement"">")
  
  '.... kompletter Inhalt, mindestens die Artikelnummer als Referenz zum Artikel
  
  ' sauber beenden
  file.writeline ("</partsmanagement>") 
  file.Close
  Set file = Nothing
  Set FSO = Nothing
  
  ' Eplan aufrufen und den Import starten
  ' 1. Teil was aufgerufen werden soll
  cmdstr = "c:\<pfad zum EPLAN>\EPLAN\Platform\[Version]\Bin\EPLAN.exe"
  ' 2. Teil welche Parameter zum Programmstart mitgegeben werden sollen
  cmdstr = cmdstr + " /Variant:""Electric P8"" /Auto /frame:0 /..."
  ' 3. Teil Import-Action mit Parameter
  cmdstr = cmdstr + " partlist /TYPE:IMPORTTOSYSTEM /IMPORTFILE:" + filename + " MODE:2"
  ' Ausführung des Befehls
  If Shell(cmdstr, vbNormalFocus) = 0 Then
    Msgbox "Es ist ein Fehler bei der Ausführung aufgetreten!"
  Else
    Msgbox "Artikel wurde(n) importiert"
  End If
End Sub

Bei dem Inhalt kommt es eben darauf an, was importiert werden soll. An der Stelle sollte, wie oben schon erwähnt, nach Möglichkeit sparsam agiert werden, denn: Im WorstCase können auch Werte gelöscht oder ungewollt überschrieben werden. Bei so versuchen, speziell bei Automatisierungen, bitte immer Backups ziehen und nicht zwingend nur auf die Backups im Unternehmen vertrauen. Die sind meistens dummerweise genau an der Stelle lückenhaft, oder zu alt (Backup morgens, die Tests laufen am Abend, oder noch schlimmer).

Was nun noch bei der Befüllung der Felder zu beachten ist: Der Datenwert und ggf. die Mehrsprachigkeit, sogenannte Multilang-Strings. Einfach gesagt sind dies Zeichenketten, die immer mit einem zB. de_DE@ für die Sprache eingeleitet werden, gefolgt von dem entsprechenden Begriff und auf ; enden. Danach kann der Begriff in der nächsten Sprache kommen. Als Beispiel (sprachunabhängig einfach ??_??@ als Sprache voranstellen:

de_DE@Inhalt des Feldes;en_US@Content of the field;

Und das ist im Grunde die ganze Magie. Wenn mehr als ein Part importiert werden soll, müssen eben mehrere Parts hintereinander geschachtelt werden. Diese könnten auch unterschiedliche Ausprägungen der zu importierenden Felder mit sich bringen, zB. Import des Feldes, nur wenn gefüllt. Hier nur beachten: Sollte das mal versehentlich gefüllt worden sein, wird es auch nicht gelöscht, die Daten bleiben in der Datenbank inkorrekt bestehen bleiben. Speziell bei Zertifikaten oder kritischen, technischen Daten sehr kritisch!