Plugin programmieren

geschrieben von boxer 
Willkommen! Anmelden Ein neues Profil erzeugen Suche
Plugin programmieren
24. November 2016 14:06
Hallo,

fakturama2 geht codemäßig in die richtige Richtung. Nun würde ich gerne versuchen, eine Erweiterung zu programmieren. Bevor ich aber die ganze Eclipse-Geschichte einrichte, interessiert mich, wie das mit der Plugin-Einbindung so läuft. Konkret denke ich an eine CMIS-Integration. Das ist ein Standard für Dokumentmanagementsysteme, wird auch von einigen freien Programmen verwendet.

Gibt es eine Dokumentation zu fakturama-Plugins? Die Übergabe der fertigen PDFs ans DMS müsste direkt nach dem Ausdruck geschehen. Aber das läuft doch komplett über Openoffice ab? Sehe ich das richtig? Warum wird für die PDF-Erzeugung Openoffice verwendet, wo es doch das Zugferd-Plugin mit pdfbox gibt?

LG
Alessandro
Re: Plugin programmieren
24. November 2016 18:31
Das ist ja gleich ein ganzer Haufen von Fragen :-)

Dann will ich mal antworten. Eine Plugin-Doku für Fakturama gibt es nicht. Generell sind das ganz normale OSGi-Plugins. Die müssen aber schon in die Startkonfiguration mit eingebunden werden. Zur Zeit ist es nicht vorgesehen, beliebige Plugins dazupacken zu können, das ist mit etwas Aufwand verbunden (geht aber prinzipiell).
Fertige PDFs können nach dem Erzeugen auch in ein bestimmtes Verzeichnis geschoben werden (dafür gibt es in Fakturama 2 eine extra Option). Dort kann sich das DMS die Datei abholen.
Das PDF wird generell über OpenOffice erzeugt, weil ich keine Bibliothek gefunden habe, die mir aus einem ODT ein gescheites PDF erzeugen kann. Deswegen muß ich das auch in Fakturama 2 noch im Hintergrund verwenden.Das ZUGFeRD-Plugin wandelt dann bloß die erzeugte PDF-Datei in ein ZUGFeRD-Dokument um.

Viele Grüße,
Ralf.
Re: Plugin programmieren
24. November 2016 20:51
OK, danke, dann kann ich mich ja am Zugferd-Plugin orientieren. Wenn was abgelegt wird, sollte es das Zugferd-PDF sein, denn dieses erhält der Kunde.

LG
Alessandro
Re: Plugin programmieren
28. November 2016 15:40
Hallo, es gibt da ein paar Dinge, die unklar bzw. ungünstig sind.

1. Zugferd-Export nur per explizitem Button-Klick ist nicht optimal. Wäre besser, das würde immer automatisch nach dem Openoffice-Druck geschehen, dann könnte man sich darauf verlassen ein fertiges Dokument zu erhalten. Nachträgliches händisches Rumkritzeln in den Dokumenten ist damit natürlich nicht mehr möglich (und auch gut so).

2. Es sollte eine Möglichkeit geben, sich an einen Event dranzuhängen. ZugferdExporter.execute() gibt immer null zurück.

3. Die Dokumente/Fakturavorgänge sollten allgemein eine Nummer enthalten, die einen Bezug zu anderen Vorgängen herstellt:
Angebot an Kunden: Angebotsnr. 0815 - Vorgangsnr. 1234
Auftrag des Kunden: Vorgangsnr. 1234
Auftragsbestätigung an Kunden: AB-Nr. 0816 - Vorgangsnr. 1234
Lieferschein, Rechnung nach demselben Schema

Man spart sich dadurch viele DMS-spezifische Anpassungen oder Sucharbeit in den Pdf-Dokumenten direkt, falls man ohne DMS arbeitet. Bezüge über Dateinamen, die auf Firmennamen basieren, sind auf Dauer unwartbar.

Ich habe bisher nur den Code von fakturama2 runtergeladen. In Sachen Zugferd-Button habe ich mich an fakturama 1.6.9 orientiert. Falls sich da was ändern wird, ist Punkt 1 natürlich obsolet.

Ist es möglich, nur eine Betaversion laufen zu lassen ohne sie zu kompilieren? Plugin einfach als jar vor dem Start ins Verzeichnis legen? Die CMIS-Aktion würde im Hintergrund laufen, es ist also kein Button oder sowas im GUI nötig.

LG, Alessandro
Re: Plugin programmieren
28. November 2016 21:15
Hallo Alessandro,
der ZUGFeRD-Export ist mal nachträglich eingebaut worden mit dem Hintergrund, daß das vielleicht nicht jeder haben will.
In Version 2 ändert sich das nochmal.
Zu 2.) Das geht IMHO nicht. Du kannst Dich maximal für ein Event registrieren, das muß aber dann vom Exporter auch geworfen werden. Ist momentan nicht vorgesehen. Bei Bedarf müssen wir das mal außerhalb des Forums besprechen. Mail siehe Impressum.
Zu 3.) Die Dateien kannst Du (fast) beliebig benennen, dafür gibt es ja die entsprechenden Platzhalter.
Fakturama 2 und Fakturama 1.6.9 sind in weiten Teilen unterschiedlich (vom Code her), deswegen kann man das nicht miteinander vergleichen.
Die Frage "Ist es möglich, nur eine Betaversion laufen zu lassen ohne sie zu kompilieren?" verstehe ich nicht. Bei Java muß man doch *immer* compilieren, sonst kommt doch kein ausführbarer Code zustande?! Einfach den Code irgendwohin zu kopieren bringt nichts, das muß miteinander schon in Verbindung gebracht werden (über die Config und die entsprechenden Plugin-Manifeste). Bei Bedarf hier ebenfalls besser per Mail.

Viele Grüße,
Ralf.
Re: Plugin programmieren
29. November 2016 10:48
Hallo Alessandro,
kleine Ergänzung zu deiner Vorgangsnummer aus Frage 3. Ich weiß ungefähr, was du beim Auslesen des Dateinamens durch die DMS beabsichtigst.

Es gibt (im Hintergrund) einen sog. Transaktionscode (für Bestellung, Rechnung, Lieferschein … identisch)
<DOCUMENT.TRANSACTION>

Der ist tatsächlich eine einheitliche Vorgangsnummer über alle Dokumente eines Vorgangs in Fakturama. Er dient aber im Grunde programminternen Zwecken und ist nicht sprechend. Auslesen kannst du ihn durch den Druck in oben genannten Platzhalter.

(Auch @Ralf) Wenn man diesen Transaktionscode als Platzhalter für die Dateinamen vorsehen würde, wäre das möglicherweise hilfreich.

Hast du, Allesandro eine gute Beschreibung, wie diese CMIS-Schnittstelle genau funktioniert? Werden nur der Dateiname ausgelesen oder noch andere Bestandteile des PDFs? Welche freien DMS hast du für eine Koppelung im Blick?

------------------
Viele Grüße
Steffen
Re: Plugin programmieren
29. November 2016 12:44
Diesen Transaktionscode muss man nicht unbedingt im Dateinamen verwenden. Er sollte aber allgemein verfügbar sein, damit man z. B. eine Vorgangs- und eine Rechnungsnummer auf der Rechnung ausdrucken kann. Bei Kundenanfragen kann man schnell alle zusammengehörenden Dokumente anhand der Vorgangsnr. raussuchen. Ob mit oder ohne DMS. Ohne DMS ist man halt auf die Suchfunktion seines Betriebssystems angewiesen und in dem Fall wäre es praktisch, wenn die Nr. im Dateinamen auftauchen würde.

CMIS ist das SQL für DMS. Ist nur eine Abfragesprache wie SQL und daher programmunabhängig. Macht man die Dokumentenübergabe zum DMS in fakturama per CMIS, kann man als DMS Alfresco, Sharepoint, Documentum etc. einsetzen ohne herstellerabhängige APIs.

Ich würde für die CMIS-Integration in fakturama eine Metadaten-Struktur packen, die man in Alfresco einspielen kann, weil diese größeren DMSe von Haus aus keine solchen Strukturen mitbringen. Das tun sie deshalb nicht, da sie weltweit und für die unterschiedlichsten Unternehmensarten eingesetzt werden. Also sowas wie Kundennr., Kundenname, Vorgangsdatum usw.

Der Dateiname spielt im DMS nur dann eine Rolle, wenn man das will. Ein Dokument in einem ordentlichen DMS muss unabhängig von seinem Dateinamen gefunden werden. Man kann per CMIS beim Hochladen den Dateinamen natürlich automatisch ändern, muss aber nicht. Solche Auswüche wie Sonder- und Leerzeichen machen einem später aber immer mal wieder zu schaffen, egal ob DMS oder nicht.

Für die Übertragung des Pdfs würde ich mich an den Daten für Zugferd orientieren und ggf. direkt aus der DB die Daten auslesen, die man braucht. Steuersatz z. B. ist irrelevant bei Dokumentenablage, es sei denn, jemand braucht das.

Alles weitere zum Programmieren werde ich per Mail an Ralf richten.

LG, Alessandro
Re: Plugin programmieren
03. Dezember 2016 14:33
Die Übertragung eines PDF-Dokumentes zum DMS per CMIS funktioniert schon mal. Nun muss das Ganze noch in fakturama eingebunden werden. Kein leichter Brocken, wenn man sich noch nie mit Eclipse-RCP auseinandergesetzt hat. Aber der Mensch wächst mit seinen Aufgaben.

Am Arbeitsplatz-PC ist ein Eclipse-RCP 4.3.2 installiert. Es ist eine von einem ERP-Hersteller angepasste Workbench, die sich aber erweitern lässt durch reguläre Eclipse-Plugins. Im fakturama2-Bitbucket-Wiki steht, dass man irgendwelche dropins ins Verzeichnis packen soll, jedoch der Link dazu führt ins Leere. ...www.fakturama.info/files/dev/dropins.zip

Die vorhandene Eclipse-Installation ist eine 64-Bit-Version, auch das neueste Eclipse Neon bekommt man für Linux nur als 64-Bit-Version. Diese 32-Bit-Altlasten werden doch nur noch unter Windows am Leben erhalten.

Kann bitte jemand den Wiki-Artikel korrigieren und mir sagen, wie ich an die Dropins komme?

LG
Alessandro
Re: Plugin programmieren
04. Dezember 2016 21:32
Hallo boxer,
ich hab den Wiki-Artikel korrigiert. Du bist ja echt zäh, das gefällt mir ;-)

Kurze Anleitung für neues Plugin:
- Workbench mit den aktuellen Sourcen einrichten und zum Laufen bekommen
- neues Plugin-Projekt erstellen (geht am besten über den Eclipse-Wizard)
- neues Feature-Projekt erstellen und das Plugin dort einbinden
- im Fakturama.product-File das Feature einbinden
- dann kannste alles mit Maven bauen (läuft über Tycho, pom.xml ist nicht mehr unbedingt notwendig) -> damit wird dann das neue Plugin auch gleich indie config eingebunden

Viele Grüße,
Ralf.
Re: Plugin programmieren
12. Dezember 2016 20:18
Freunde, ich komm nicht weiter. Die Teams-Datei verweist auf falsche Pfade. Ist wohl noch nicht auf dem aktuellen fakturama2-Stand. Da sogar Grundfunktionen wie JPA-Entities von Plugin-Plugins generiert werden, bin ich total abgeschnitten. Maven ist dazu gemacht, sich nicht an irgendwelche Buildskripte zu binden, aber Tycho untergräbt das. Wozu der lib-Ordner bei Zugferd, wenn es doch im pom.xml drin steht? Ich werde jetzt die CMIS-Geschichte separat erstellen, auch die entsprechenden Entities und JPA-Controller dazu. Danach wird ein Eclipse-Plugin aus dem jar erstellt.

Um wenigstens ein paar konkrete Angaben zu den Metadaten zu erhalten, die ans DMS mitgeliefert werden sollen, mache ich einen anderen Thread auf.

Wie lauten die Dokumentenpfade in einer nicht deutschsprachigen fakturama2-Installation?

Ralf meinte, dass man Beispieldaten aus dem Shop-Connector herunterladen könne. Weiß jemand, wo die sind? Ich find nix. Leider scheint Ralf zur Zeit nicht erreichbar zu sein.

Vielen Dank an jeden, der mir vor Weihnachten noch weiterhelfen kann.

LG, Alessandro
Re: Plugin programmieren
13. Dezember 2016 08:07
Hallo Alessandro,

bei deine Java Fragen kann ich dir leider nicht weiterhelfen. Die Beispieldaten bekommst du, wenn du mit dem voreingestellten Connector die Webshop Bestellungen abrufst.
[fakturama.sebulli.com]

Gruß
moped
Re: Plugin programmieren
13. Dezember 2016 16:56
Danke, habe es gefunden. Was ich jetzt noch bräuchte, sind die einzelnen Dokumente, die fakturama erstellen kann. Lieferscheine, Rechnungen usw. in ihren Ordnerstrukturen im Arbeitsverzeichnis.

LG,
Alessandro
Re: Plugin programmieren
13. Dezember 2016 20:27
Hi, ich bin eigentlich da...
Die Vorlagen-Dokumente befinden sich in Fakturama-Parent\com.sebulli.fakturama.resources.templates\src\main\resources\Templates (im Git).

Das mit dem tycho hab ich deswegen genommen, weil man damit die komplette Anwendung bauen kann (außerhalb von Eclipse). Tycho sorgt im Prinzip dafür, daß die Abhängigkeiten eben nicht mehr aus dem pom gelesen werden sondern aus den Manifest-Dateien. Das hat den Vorteil, daß man die Abhängigkeiten nicht an zwei unterschiedlichen Stellen pflegen muß. Neuerdings braucht man bei einfachen Plugins gar kein pom mehr, das wird gleich so gebaut.

In der Teamset-Datei stehen eigentlich gar keine Pfade drin, bis auf den Git-Zugang.

Der lib-Ordner im zugferd-Plugin eine Frustreaktion von mir gewesen, weil Eclipse die Dateien partout nicht auflösen wollte. Möglicherweise kann das wirklich weg. Muß ich mir nochmal ansehen.

Die JPA-Entities werden über Texo generiert, das ist aber IMHO eine relativ coole Geschichte, weil man damit im Prinzip gleich die Doku (für die Entities) mit abhandelt. Außerdem hat man im Modell gleich alles zusammen in einer Übersicht und man kann daraus sogar eine Graphik zaubern. Und außerdem spart man sich 'ne Menge Schreibarbeit :-) Die Generierung und die Einrichtung dazu hatte ich aber im Wiki beschrieben und auch getestet, das dürfte funktionieren. Die Entities für die Altdaten hatte ich mit Hilfe der EclipseLink Workbench generiert, war 'ne einmalige Sache. Die Quellen dazu sind aber auch im Git drin.

Achso - der Beispiel-Shop ist hier:

[shop.fakturama.info]

und für die Version 1.x: [shop.fakturama.info]

Hilft das weiter?

Viele Grüße,
Ralf.
Re: Plugin programmieren
14. Dezember 2016 18:04
Mag sein, dass Tycho, Texo usw. eine Hilfe ist, wenn man sich nur im Eclipse-Kreis bewegt. Das sperrt aber Leute aus, die nur mit den herkömmlichen Tools vertraut sind. Vieles was in Eclipse nur mit zig Plugins zu bewerkstelligen ist, ist in Netbeans schon integriert. Z. B. die Generierung von JPA-Klassen so wie bei den Altdaten. Ich bevorzuge Netbeans und mache nur das Allernötigste in Eclipse oder Intellij.

Trotz komplett neuer Eclipse-Installation lässt sich die Teams-Datei nicht importieren. Es werden Unterprojekte nicht gefunden, die wohl in fakturama2 nicht mehr existieren.

In Netbeans hatte ich den Code aus Bitbucket geklont, aber beim Kompilieren fehlt dann doch Eclipse-RCP-Code. Den gibts wohl nicht komplett über Maven. Diese Vorgehensweise werde ich jetzt auch mal in Eclipse ausprobieren, ohne Teams-Datei.

Zitat
rheydenr
Der lib-Ordner im zugferd-Plugin eine Frustreaktion von mir gewesen, weil Eclipse die Dateien partout nicht auflösen wollte. Möglicherweise kann das wirklich weg. Muß ich mir nochmal ansehen.

Das war mein einziger Notnagel, das und die Manifest-Datei und die Altdaten-Entities.

LG, Alessandro
Re: Plugin programmieren
15. Dezember 2016 19:25
Hallo Alessandro, Du brauchst aber das Laufzeitsystem von Eclipse, damit die Anwendung läuft. In Netbeans gibt's kein OSGi (glaube ich), und Fakturama 2 läuft über OSGi (Equinox). Du kannst im Eclipse auch einfach das Fakturama-Parent-Projekt klonen und dann per Projektimport (bestehendes Maven-Projekt) importieren. Dann baut es die Struktur auch auf.

Viele Grüße,
Ralf.
In diesem Forum dürfen leider nur registrierte Teilnehmer schreiben.

Klicke hier, um Dich einzuloggen