OfficeIntegration mit Chromium
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Wir nutzen im Bereich WD4A die OfficeIntegration um Worddokumente verarbeiten zu können - z.B. mit MERGE_FIELDS. Immer mehr Browser auch der NWBC werden nun auf Chromium* umgestellt. Dabei funktioniert aber das ACF-Plugin der SAP nicht mehr und damit auch nicht mehr die OfficeIntegration.
Wir hatten nun einen OSS-Meldung bei der SAP offen, um nach Alternativen zu fragen. Laut SAP gibt es hierfür aktuell keine Altertive.
Daher die Frage hier:
Wie löst ihr die OfficeIntegration, wenn der Browser auf Chromium läuft?
Gibt es alternative Plugins?
Laut OSS-Hinweis läuft auch Adobe Interactiv Forms nicht mehr unter Chromium.
*Chromium; nicht googleChrome.
Wir hatten nun einen OSS-Meldung bei der SAP offen, um nach Alternativen zu fragen. Laut SAP gibt es hierfür aktuell keine Altertive.
Daher die Frage hier:
Wie löst ihr die OfficeIntegration, wenn der Browser auf Chromium läuft?
Gibt es alternative Plugins?
Laut OSS-Hinweis läuft auch Adobe Interactiv Forms nicht mehr unter Chromium.
*Chromium; nicht googleChrome.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von Lukas Sanders (ForumUser / 69 / 7 /
34
)
»
Da wir von der SAP auch nichts zu einer Nachfolgelösung gehört haben, haben wir uns zunächst damit beholfen, Word-Vorlagen mithilfe der Klasse CL_DOCX_DOCUMENT einzulesen und das XML des Dokumententeils zu manipulieren.
Hierbei haben wir entsprechende Platzhalter gesetzt, die man später programmatisch ersetzen kann.
Durch ein wenig Analyse des XML-Standards ist es uns gelungen, damit nicht nur Mergefields zu ersetzen, sondern auch formatierte Tabellen und Textbausteine einzufügen.
Ansonsten haben wir noch eine Klasse im Blick die Word-Dokumente "aus dem Nichts" erstellt und binär zurückliefert (https://blogs.sap.com/2015/11/16/genera ... e-in-abap/). Nach etwas "Rumprobieren" und Feinschliff konnten wir damit sehr brauchbare Dokumente generieren, allerdings mit viel statischem Code pro Dokument.
Auch den XSLT-Dateiaustausch (https://blogs.sap.com/2016/02/17/genera ... amic-data/) haben wir in Erwägung gezogen, aber noch nicht eingesetzt.
Beide Lösungen sind zwar kein echter Schnittstellenersatz, wir haben aber auch nur sehr wenige Word-Dokumente im Einsatz. Eventuell kann man sich aus einer dieser Lösungen ein eigenes brauchbares Framework basteln.
Hierbei haben wir entsprechende Platzhalter gesetzt, die man später programmatisch ersetzen kann.
Durch ein wenig Analyse des XML-Standards ist es uns gelungen, damit nicht nur Mergefields zu ersetzen, sondern auch formatierte Tabellen und Textbausteine einzufügen.
Ansonsten haben wir noch eine Klasse im Blick die Word-Dokumente "aus dem Nichts" erstellt und binär zurückliefert (https://blogs.sap.com/2015/11/16/genera ... e-in-abap/). Nach etwas "Rumprobieren" und Feinschliff konnten wir damit sehr brauchbare Dokumente generieren, allerdings mit viel statischem Code pro Dokument.
Auch den XSLT-Dateiaustausch (https://blogs.sap.com/2016/02/17/genera ... amic-data/) haben wir in Erwägung gezogen, aber noch nicht eingesetzt.
Beide Lösungen sind zwar kein echter Schnittstellenersatz, wir haben aber auch nur sehr wenige Word-Dokumente im Einsatz. Eventuell kann man sich aus einer dieser Lösungen ein eigenes brauchbares Framework basteln.
Folgende Benutzer bedankten sich beim Autor Lukas Sanders für den Beitrag (Insgesamt 2):
msfox • ewx
Hallo Lukas,
könnt ihr damit Office-Dokument im Browser auch direkt darstellen, der Anwender kann etwas ändern und dieses an direkt wieder hochladen?
Also ohne, dass er es zuvor bei sich auf dem Desktop speichern muss.
---
Bei uns betrifft es eine unbegrenzte Anzahl an Dokumenten, da unser Produkt für ein Rechenzentrum und im öffentlichen Sektor eingesetzt wird.
Danke.
könnt ihr damit Office-Dokument im Browser auch direkt darstellen, der Anwender kann etwas ändern und dieses an direkt wieder hochladen?
Also ohne, dass er es zuvor bei sich auf dem Desktop speichern muss.
---
Bei uns betrifft es eine unbegrenzte Anzahl an Dokumenten, da unser Produkt für ein Rechenzentrum und im öffentlichen Sektor eingesetzt wird.
Danke.
Beitrag
von Lukas Sanders (ForumUser / 69 / 7 /
34
)
»
Hallo msfox,
wir können bisher nur Dokumente erstellen und dann zum Download anbieten, Darstellen oder Bearbeiten im Browser funktioniert damit leider nicht.
Soweit ich (noch) richtig informiert bin, kann Chromium (oder jeder andere aktuelle Browser) gar keine Office-Dokumente verarbeiten und der Internet Explorer war hier durch die starke Integration nur ein Sonderfall.
Man müsste also sowohl für die Darstellung als auch für das Zurückschreiben der Änderungen eine geeignete Lösung finden, vor allem letzteres dürfte (besonders ohne SAP GUI) schwierig werden.
Eventuell wäre der IE-Modus vom Edge Chromium noch eine Alternative.
wir können bisher nur Dokumente erstellen und dann zum Download anbieten, Darstellen oder Bearbeiten im Browser funktioniert damit leider nicht.
Soweit ich (noch) richtig informiert bin, kann Chromium (oder jeder andere aktuelle Browser) gar keine Office-Dokumente verarbeiten und der Internet Explorer war hier durch die starke Integration nur ein Sonderfall.
Man müsste also sowohl für die Darstellung als auch für das Zurückschreiben der Änderungen eine geeignete Lösung finden, vor allem letzteres dürfte (besonders ohne SAP GUI) schwierig werden.
Eventuell wäre der IE-Modus vom Edge Chromium noch eine Alternative.
Folgende Benutzer bedankten sich beim Autor Lukas Sanders für den Beitrag:
msfox
Aktuell nutzen unsere Kunden den "IE11-Modus in MS Edge", der aber laut diesem "Hinweis: 1672817 - Browser: Hinweis zu Support-Richtlinien für Microsoft Legacy Edge und Internet Explorer" spätestens 2027 endet.
Daher haben wir uns auch über eine down- und upload-Funktion entschieden.
--
Soweit ich mir das technisch erkläre, übergab man bisher dem DOCX eine Liste mit Key/Value für die MergeFelder. Erst zur Laufzeit im ActivX (ACF) hat MS Office diese auf die MergeFelder geschrieben.
Jetzt muss das quasi vorher selbst machen.
Aber bleiben es dann MergeFelder oder ersetzt ihr das MergeFeld komplett durch den realen Inhalt?
Daher haben wir uns auch über eine down- und upload-Funktion entschieden.
Hast du dafür mal "3 Zeilen" Quellcode?Lukas Sanders hat geschrieben: ↑14.05.2020 17:04Durch ein wenig Analyse des XML-Standards ist es uns gelungen, damit nicht nur Mergefields zu ersetzen,
--
Soweit ich mir das technisch erkläre, übergab man bisher dem DOCX eine Liste mit Key/Value für die MergeFelder. Erst zur Laufzeit im ActivX (ACF) hat MS Office diese auf die MergeFelder geschrieben.
Jetzt muss das quasi vorher selbst machen.
Aber bleiben es dann MergeFelder oder ersetzt ihr das MergeFeld komplett durch den realen Inhalt?
Laut Blog nutzt diese Klasse aber OLE, was für Webdynpros eher nicht geeignet ist.Lukas Sanders hat geschrieben: ↑14.05.2020 17:04Ansonsten haben wir noch eine Klasse im Blick die Word-Dokumente "aus dem Nichts" erstellt und binär zurückliefert
Beitrag
von Lukas Sanders (ForumUser / 69 / 7 /
34
)
»
Im Grunde wurden einfach die Mergefields vollständig durch Inhalt ersetzt, sie wurden also nur als Platzhalter eingefügt. Ungefähr nach diesem Muster (auf das eigentliche Programm habe ich leider keinen Zugriff mehr):msfox hat geschrieben: ↑12.09.2022 09:27Hast du dafür mal "3 Zeilen" Quellcode?Lukas Sanders hat geschrieben: ↑14.05.2020 17:04Durch ein wenig Analyse des XML-Standards ist es uns gelungen, damit nicht nur Mergefields zu ersetzen,
--
Soweit ich mir das technisch erkläre, übergab man bisher dem DOCX eine Liste mit Key/Value für die MergeFelder. Erst zur Laufzeit im ActivX (ACF) hat MS Office diese auf die MergeFelder geschrieben.
Jetzt muss das quasi vorher selbst machen.
Aber bleiben es dann MergeFelder oder ersetzt ihr das MergeFeld komplett durch den realen Inhalt?
Code: Alles auswählen.
* 1. Dokument irgendwo herholen und ggf. in XSTRING konvertieren
* 2. Dokument in Klasse CL_DOCX_DOCUMENT laden
CALL METHOD cl_docx_document=>load_document
EXPORTING
iv_data = xstring
RECEIVING
rr_doc = docx.
* 3. Inhaltsteil holen (als XML, XSTRING)
xml = docx->get_maindocumentpart( )->get_data( ).
* 4. XML in String umwandeln
string = CL_BCS_CONVERT=>XSTRING_TO_STRING( IV_XSTR = xml IV_CP = 'Codepage' ).
* 5. Für jedes Feld entsprechend Ersetzung vornehmen
REPLACE ALL OCCURRENCES OF '«Name_des_Mergefields»' IN string WITH wert.
Die Lösung ist natürlich ziemlich unsauber und unflexibel - da es aber unbedingt ganz schnell gehen musste und die Anzahl an Dokumenten begrenzt war, ist es dieses Dauerprovisorium geworden.
Ich rufe die u.a. aus einer Fiori-Oberfläche über einen Webservice auf, das klappt bisher problemlos.msfox hat geschrieben: ↑12.09.2022 09:27Laut Blog nutzt diese Klasse aber OLE, was für Webdynpros eher nicht geeignet ist.Lukas Sanders hat geschrieben: ↑14.05.2020 17:04Ansonsten haben wir noch eine Klasse im Blick die Word-Dokumente "aus dem Nichts" erstellt und binär zurückliefert
Den Weg sind wir jetzt auch gegangen, nach der gleichen Logik. Nur Punk 5 ist etwas aufwendiger.Lukas Sanders hat geschrieben: ↑15.11.2022 07:55Im Grunde wurden einfach die Mergefields vollständig durch Inhalt ersetzt, sie wurden also nur als Platzhalter eingefügt.
Es gibt bei uns Kunden mit sehr vielen Dokumenten die noch in "doc" erstellt und irgendwo nur als "docx" gespeichert wurden. Dort sind die MERGE_FIELDS noch nicht duch « und » gekennzeichnet. D.h. man muss erst die Definition des MERGE_FIELDS (MergeID) ermitteln und erst die nächstfolgenden Zeichenkennte mit dieser ID ist dann der Teil, den man ersetzt. Die Ermittlung der Merge-ID ist auch nicht ohne, da die Kunden auch die Optionen für "Text davor" "Text danach" etc. verwenden. "Text davor" "Text danach" muss dann natürlich auch mit an diese Stelle kommen. Auch wird die Definition der Merge-ID mal als XML-Tag und mal als XML-Attribut gekennzeichnet.Lukas Sanders hat geschrieben: ↑15.11.2022 07:55Code: Alles auswählen.
* 5. Für jedes Feld entsprechend Ersetzung vornehmen REPLACE ALL OCCURRENCES OF '«Name_des_Mergefields»' IN string WITH wert.
Weiterhin müssen bestimmte Zeichen noch cascadiert werden - z.B. &,...
--
Ja, das ist sehr aufwendig, aber aktuell kamen keine weiteren Fehlermeldungen vom Kunden rein.
Beitrag
von Lukas Sanders (ForumUser / 69 / 7 /
34
)
»
Probleme dieser Art hatten wir auch, der gesamte Prozess war auch eher ein laufendes Experimentieren und Anpassen (heute würde man das vermutlich agil nennen). Bei Änderungen gibt es auch regelmäßig Anpassungsbedarf, allein weil unsere Lösung als Provisorium nicht besonders dynamisch gestaltet war (neues Feld = Programmänderung etc.).
Da SAP noch immer keine wirkliche Abhilfe in Aussicht gestellt hat, hat man sich bei uns inzwischen auch externe Lösungen angesehen. Bedeutet zwar zusätzliche Kosten, aber dafür sicherlich verlässlicher und einfacher zu warten als so eine Eigenprogrammierung.
Folgende Benutzer bedankten sich beim Autor Lukas Sanders für den Beitrag:
msfox
Seite 1 von 1
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.