Schnittstelle zu ms-COM (excel,outlook,...) via groovy

Es freut mich, dass groovy wieder unterstützt wird, siehe groovy-callouts-in-metasfresh. In unserem heutigem Gespräch mit @metasnw habe ich zugesagt, die Schnittstelle zu ms-COM zu beschreiben. Als Beispiel nehme ich das Datenblatt (excel) mit Endkundendaten, das per Knopfdruck oder Callout erzeugt werden kann. Zunächst die Architektur als Skizze:

  • links die groovy engine, beispielsweise in mf swingUI

  • sie wird etwa beim Callout gestartet und interpretiert ein Skript, das aus Tabelle ad_rule geladen wird

  • dh. die notwendigen Komponenten werden zur Laufzeit benötigt

  • im script steht import org.codehaus.groovy.scriptom.ActiveXObject - diese Klasse bildet die api zwischen groovy und jacob (JAva-COM Bridge) und wird im scriptom.jar vom groovy Anbieter codehaus bereitgestellt

  • beide jars werden also zu Laufzeit geladen und von groovy angebunden

  • dazu muss das build in metasfresh erweitert werden, z.B. in metasfresh\de.metas.adempiere.adempiere\client\pom.xml:

      <!-- runtime support for COM-api excel/outlook -->
          <dependency>
              <groupId>org.codehaus.groovy.modules.scriptom</groupId>
              <artifactId>scriptom</artifactId>
              <version>1.6.0</version>            
              <scope>runtime</scope>
          </dependency>
          <dependency>
              <groupId>com.hynnet</groupId>
              <artifactId>jacob</artifactId>
              <version>1.18</version>
              <scope>runtime</scope>
          </dependency>
    
  • PS: die früheren jacob versionen hatten einen anderen Herausgeber jacob-1.14.3.jar : net.sf.jacob-project

  • um auf die COM-Komponenten von Windows zuzugreifen werden schliesslich noch zwei dlls aus der Java Desktop Integration benötigt jdic.dll und tray.dll : wie man die per maven definiert ist mir nicht klar (das können die metas-maven-Experten sicher :v:). So etwa habe ich es mir gedacht:

<dependency>
    <groupId>com.hynnet</groupId>
    <artifactId>jacob</artifactId>
    <version>1.18</version>
    <classifier>x86</classifier>
    <type>dll</type>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>com.hynnet</groupId>
    <artifactId>jacob</artifactId>
    <version>1.18</version>
    <classifier>x64</classifier>
    <type>dll</type>
    <scope>runtime</scope>
</dependency>

Liebe metas-Kollegen, gerne stelle ich Euch für Testzwecke ein groovy-Skript zur Verfügung.
Erstmal warte ich auf die nächste mf-Version mit groovy.
Gruß

hier die jacob 1.18 komponenten mit jar und dlls

ich habe ein Ticket für den ersten Teil definiert : https://github.com/metasfresh/metasfresh/issues/695 und liefere auch die Lösung als pull request dazu.

Die notwendigen dlls jacob-1.18-x64.dll muss der Nutzer selber in ein win-PATH Verzeichnis kopieren,
solange der zweiter Teil nicht implementiert ist.

Guten Morgen @metasnw,
nachdem der pull mit der pom Lösung ohne commit geschlossen wurde, haben wir gestern über eine Alternative gesprochen:

  • der client wird um ein Verzeichnis userlib erweitert
  • dieses ist per default leer, der Nutzer kann dort eigene jars hineinkopieren
  • diese jars werden dem CLASSPATH beim start von mf vorangestellt

Gefallen würde mir zusätzlich dieses:

  • ins Verzeichnis userlib-x64 kann der user dlls kopieren die mf dem PATH voranstellt

Ich warte auf das erste Release mit diesem feature.

Hallo homebeaver,
vielen dank für deine Rückinfo.

Ja, wir konnten deinen PR es leider nicht nach master übernehmen weil es nicht den Entwicklungs- und Qualitätskriterien unserer Community enspricht. Tobias @metas-ts hatte dir vorab im Pull-Request die Situation beschrieben, einen Lösungsvorschlag gemacht und seine Hilfe angeboten. Nach einiger Zeit ohne Aktivität und Dialogaufnahme deinerseits im Pull Request wurde der PR geschlossen und begründet. Ich hoffe du hast Verständnis dafür, wir haben es halt gerne aufgeräumt. :wink:

Soweit ich sehen kann greift Deine o.g. Alternative den Vorschlag von @metas-ts vom 16.01. auf.

We think that the right way to go about this is to let the metasfresh client discover external libaries on startup and load them.

Ich denke damit ist eine gute Basis geschaffen um sich gemeinsam über eine gute Lösung abzustimmen.

Ich freue mich auf eine gute Zusammenarbeit.:wink:

Viele Grüße
Mark

Hi Mark,
wir haben gestern eine gute Lösung abgestimmt.
@metasnw hat uns gestern zugesagt, dass er ein issue anlegen wird, damit ihr das feature implementieren könnt. Wie ist die issue id? Ich habe keine gefunden.

Hi,

ich habe gestern gesehen dass der Original Issue noch offen ist, also nehmen wir den doch:

Viele Grüße
Norbert

danke. Ich fasse die spec zusammen:

  • userlib : will be the first part - the jars needed
  • userlib-x64 : second will be the dlls
  • userlib-x86 : nur der Vollständigkeit halber. Will jemand noch 32-bit? ich glaube nein.

Bitte so den client start implementieren.

Hallo @homebeaver,
ich habe hier geantwortet.
Nach kurzer Recherche erscheint mir die Implementierung recht simpel. Es muss nur eine Datei bereitgestellt bzw. einige Kommandozeilenparameter hinzugefügt werden.

Bitte sag Bescheid, wenn ich etwas missverstanden oder übersehen habe.

Viele Grüße
Tobias

Danke @metas-ts,
am Wochenende habe ich bei “interceptor” nicht an metasfresh gedacht :football: .
Deine simple Implementierung habe ich nicht ganz verstanden, aber es sollte einfach sein.
Ich mache mal das typische, einfache “HalloWorld”- Beispiel.

  1. ich kopiere ein HelloWorld.jar ins Verzeichnis %METASFRESH_HOME%/userlib

  2. für ms-COM sind es jacob.jar und scriptom-1.6.0.jar, für openTRANS andere

  3. HelloWorld.jar hat nur diese Klasse:

    package my.local;
    public class HelloWorld {
    	public static String helloWorld() {
    		return "Hello World!";
    	} ...
  1. das groovy-Skript, dass die Klasse aus dem jar nutzt sieht so aus:
package de.mf.demo
import groovy.lang.Binding
import groovy.lang.Script
import my.local.HelloWorld

class Hello extends Script {

	public Hello() { }
	public Hello(Binding binding) {
		super(binding);
	}

	@Override
	public Object run() {
		return HelloWorld.helloWorld();
	}
}
  1. ich kann das groovy in ad-rule speichern, ein mf-Prozess definieren und ausführen

Im aktellen mf-Release liefert der Prozess eine Exception, weil das jar ja keine mf-Komponente ist.
PS: Die demo habe ich lokal via eclipse erstellt, wo der PR #697 aktiv ist

Oops,
wie ist das zu verstehen? Wer implementiert?

Please let us know what you need to further proceed on implementing this feature for your customer.

Beim Gespräch mit nw, haben wir verstanden, dass metas diese einfache Lösung implementiert. Davon gehen wir nachwievor aus.

OK, ich habe die Implementierung als pull/962 bereitgestellt.

1 Like

Danke Dir für das Bereitstellen des Pull Request!