FrameMaker 2020: SharePoint 2013 als Repository?

[I. Burk]

Hallo zusammen,

für unser Team suche ich eine Dateiverwaltungssystem, das Funktionen wie Versionskontrolle, Offline-Arbeit, gemeinsame Nutzung der Dateien bereitstellt.

In unserem Haus soll SharePoint 2013 als zentrales Dateimanagementsystem eingesetzt werden.

Ein erster Versuch mit dem SharePoint-Konnektor von FrameMaker 2020 verlief eher enttäuschend:

Auschecken ganzer Ordner ist nicht möglich, sondern nur ein Auschecken einzelner Dateien.

Herunterladen von Dateien oder Ordner führt dazu, dass die nativen FM-Dateien nicht mehr gelesen werden können, sondern als txt-Dateien eingelesen und konvertiert werden müssen. Wahlweise sind andere Formate wie xml möglich.

Checke ich eine heruntergeladene Datei aus, wird die lokale Datei durch das Auschecken gelöscht (!). 

Hochgeladene Dateien werden nicht als neue Versionen der auf SharePoint abgelegten Dateien erkannt. Sie werden als neue Dateien integriert mit zusätzlicher Zählung in Klammern, also Dok(1).fm.

Für mich sieht es so aus, als würden FrameMaker und SharePoint nicht ordentlich zusammenarbeiten.

Da ein Repository in Zukunft zwingend erforderlich ist, brauche ich eine Alternativlösung.

Welche Versionskontrollsysteme (Subversion, Tortoise SVN, Git/GitHub, ...) können mit FM-Dateien umgehen? Oder gibt es eine andere Lösung, um eine Zusammenarbeit und eine gemeinsame Nutzung der FM-Dokumente möglich zu machen?

Vielen Dank für eure Hilfe!

I. Burk

[Johannes Graubner (Transcom)]

Hallo I.,

 

Du kannst die Documents eines SharePoints in das Dateisystem des Windows Explorers einbinden:

 

Effektiv ist das eine WebDAV-Verbindung:

\\xyz.sharepoint.com@SSL\DavWWWRoot\sites\12345678\AbcD

 

Dann sollte auch FrameMaker auf den SharePoint als Dateisystem zugreifen können.

 

Das funktioniert nach meiner Kenntnis jedoch nur mit dem Internet Explorer – und der ist de facto abgekündigt. Mir ist kein aktueller Browser bekannt, in dem der Menüpunkt ebenfalls verfügbar wäre, und auch kein Work-around, um ohne Internet Explorer dasselbe Ergebnis zu gewinnen. Es gibt allerdings für kleines Geld WebDAV-Clients, die einen SharePoint ebenfalls in das Dateisystem einbinden können.

 

Viele Grüße

Johannes

--
Für Nachrichten an den »Eigentümer« der Gruppe, senden Sie eine E-Mail an frameuser...@googlegroups.com
---
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "frameusers-de" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an frameusers-d...@googlegroups.com.
Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/a5221306-c1b3-4619-98ee-153bd1244926n%40googlegroups.com auf.

[I. Burk]

Ah, sehr interessant. Insbesondere deswegen, weil der neueste FrameMaker "noch einfacher" mit SharePoint umgehen kann - laut Adobe.

Ich bin soweit gekommen, dass ich eine Verbindung über den Repository-Manager habe anlegen können. Die Dateien können dort ausgecheckt und eingecheckt werden. Es gibt jedoch einige größere Probleme (wie bereits oben geschildert).

Kann ein solcher WebDAV-Client das erledigen, was von uns gefordert ist? Also Offline-Arbeit, Aus- und Einchecken, Versionierung, automatische Aktualisierung lokaler Kopien (ev. nach Abfrage), ...

Oder ist hier ein "richtiges" Versionskontrollsystem gefragt?

[Johannes Graubner (Transcom)]

Hallo i.,

 

da ich bislang nicht versucht habe, SharePoint (oder irgendeine andere Cloud) als Repository für FrameMaker einzusetzen: Bitte die Fragen selbst untersuchen. Ich würde erwarten, dass viel auch davon abhängt, wie der SharePoint eingestellt ist, beispielsweise wie viele Versionen angelegt werden (ehe wieder gelöscht wird), wie viel Speicherplatz dem SharePoint zugewiesen ist, welcher Datei-Locking-Mechanismus gesetzt ist (sperrt das Öffnen einer Datei den Zugriff für andere oder können Dritte weiterhin darauf zugreifen) etc. pp.

 

Viele Grüße

Johannes

 

Von: 'I. Burk' via frameusers-de <frameu...@googlegroups.com>
Gesendet: Montag, 31. Mai 2021 17:20
An: frameusers-de <frameu...@googlegroups.com>
Betreff: Re: [frameusers-de] FrameMaker 2020: SharePoint 2013 als Repository?

 

Ah, sehr interessant. Insbesondere deswegen, weil der neueste FrameMaker "noch einfacher" mit SharePoint umgehen kann - laut Adobe.

 

Ich bin soweit gekommen, dass ich eine Verbindung über den Repository-Manager habe anlegen können. Die Dateien können dort ausgecheckt und eingecheckt werden. Es gibt jedoch einige größere Probleme (wie bereits oben geschildert).

Kann ein solcher WebDAV-Client das erledigen, was von uns gefordert ist? Also Offline-Arbeit, Aus- und Einchecken, Versionierung, automatische Aktualisierung lokaler Kopien (ev. nach Abfrage), ...

Oder ist hier ein "richtiges" Versionskontrollsystem gefragt?

grau...@transcom.de schrieb am Montag, 31. Mai 2021 um 15:34:13 UTC+2:

Hallo I.,

 

Du kannst die Documents eines SharePoints in das Dateisystem des Windows Explorers einbinden:

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/f6c47f4a-bf95-4c5b-90a9-82c3effb8b15n%40googlegroups.com auf.

[Springer Michael]

Hallo Zusammen,

 

ich hatte gestern schon geantwortet zu meinen eigenen Erfahrungen, aber der Text ist irgendwie nicht in der Gruppe erschienen. Hier der 2. Versuch

 

ich nutze als Repository SVN auf einem eigenen virtuellen Server mit Tortoise SVN als Client. Es funktioniert im Prinzip, aber man muss auf die ganzen Benefits, was eine Versionskontrolle so mit sich bringt, mehr oder weniger verzichten. Das liegt an mehreren Gründen (meiner Meinung nach).

- .fm-Dateien sind eine Mischung aus dem geschriebenen Fließtext und binären Einheiten, die die Formatierung beinhalten. Somit kann man keinen direkten Versionsvergleich machen, was hat sich zum Vorgänger verändert. Man könnte das Problem theoretisch umgehen, indem man alle Dateien als .mif abspeichert. Ist aber wieder mit extra Workflow/Arbeit verbunden.

- Bei jedem Speichern in Framemaker erzeugt man sich eine neue Revision (auch wenn eigentlich nichts im Dokument geändert wurde). Der Grund ist, dass die Seiten und Absätze einen „Unique“-Parameter haben. Beispiel:

  <Para

  <Unique 1091388>

Die werden bei jedem Speichern hochgezählt und somit erzeugt man jedes Mal eine neue Revision.

- Wenn man eine Datei in mehreren Büchern eingebunden hat, wird bei jedem Buch aktualisieren z. B. die Seitenzahl in den einzelnen Dokumenten geändert, was bei Speichern wiederum eine neue Version erzeugt. Selbst wenn sich nur eine Variable, wie eine Artikelnummer ändert und sonst nichts. Somit kriegt man von allen Dateien im Buch jedes Mal (wenn gespeichert wird) eine neue Version.

 

Meine Erfahrung sagt mir, eine wirkliche Top-Lösung die alles beherrscht von der Stange weg gibt es da nicht, weil Framemaker durch seine Programmierung und dem Verwalten von manchen Dingen per se für ein Versionskontrollsystem a la SVN massig neue Revisionen erzeugt. Mit Scripten kann man sicherlich noch was hinbiegen. Aber das muss dann halt wieder auf den individuellen Workflow angepasst werden.

 

Ich nutze SVN, dass ich überhaupt eine Versionkontrolle habe, aber glücklich bin ich damit nicht wirklich.

 

Soweit meine Erfahrungen zu SVN. Zu den anderen Lösungen wie SharePoint u. a. kann ich nichts sagen. Ich nutze auch keine XML, sondern nur .book und .fm

 

Grüße

M. Springer

 

 

Von: frameu...@googlegroups.com <frameu...@googlegroups.com> Im Auftrag von Johannes Graubner (Transcom)
Gesendet: Montag, 31. Mai 2021 17:57
An: frameu...@googlegroups.com
Betreff: AW: [frameusers-de] FrameMaker 2020: SharePoint 2013 als Repository?

 

Hallo i.,

 

da ich bislang nicht versucht habe, SharePoint (oder irgendeine andere Cloud) als Repository für FrameMaker einzusetzen: Bitte die Fragen selbst untersuchen. Ich würde erwarten, dass viel auch davon abhängt, wie der SharePoint eingestellt ist, beispielsweise wie viele Versionen angelegt werden (ehe wieder gelöscht wird), wie viel Speicherplatz dem SharePoint zugewiesen ist, welcher Datei-Locking-Mechanismus gesetzt ist (sperrt das Öffnen einer Datei den Zugriff für andere oder können Dritte weiterhin darauf zugreifen) etc. pp.

 

Viele Grüße

Johannes

 

Von: 'I. Burk' via frameusers-de <frameu...@googlegroups.com>
Gesendet: Montag, 31. Mai 2021 17:20
An: frameusers-de <frameu...@googlegroups.com>
Betreff: Re: [frameusers-de] FrameMaker 2020: SharePoint 2013 als Repository?

 

Ah, sehr interessant. Insbesondere deswegen, weil der neueste FrameMaker "noch einfacher" mit SharePoint umgehen kann - laut Adobe.

 

Ich bin soweit gekommen, dass ich eine Verbindung über den Repository-Manager habe anlegen können. Die Dateien können dort ausgecheckt und eingecheckt werden. Es gibt jedoch einige größere Probleme (wie bereits oben geschildert)..

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/004f01d75635%248d39a660%24a7acf320%24%40transcom.de auf.

[Springer Michael]

Hallo Zusammen,

 

ich nutze als Repository SVN auf einem eigenen virtuellen Server mit Tortoise SVN als Client. Es funktioniert im Prinzip, aber man muss auf die ganzen Benefits, was eine Versionskontrolle so mit sich bringt, mehr oder weniger verzichten. Das liegt an mehreren Gründen (meiner Meinung nach).

- .fm-Dateien sind eine Mischung aus dem geschriebenen Fließtext und binären Einheiten, die die Formatierung beinhalten. Somit kann man keinen direkten Versionsvergleich machen, was hat sich zum Vorgänger verändert. Man könnte das Problem theoretisch umgehen, indem man alle Dateien als .mif abspeichert. Ist aber wieder mit extra Workflow/Arbeit verbunden.

- Bei jedem Speichern in Framemaker erzeugt man sich eine neue Revision (auch wenn eigentlich nichts im Dokument geändert wurde). Der Grund ist, dass die Seiten und Absätze einen „Unique“-Parameter haben. Beispiel:

  <Para

  <Unique 1091388>

Die werden bei jedem Speichern hochgezählt und somit erzeugt man jedes Mal eine neue Revision.

- Wenn man eine Datei in mehreren Büchern eingebunden hat, wird bei jedem Buch aktualisieren z. B. die Seitenzahl in den einzelnen Dokumenten geändert, was bei Speichern wiederum eine neue Version erzeugt. Selbst wenn sich nur eine Variable, wie eine Artikelnummer ändert und sonst nichts. Somit kriegt man von allen Dateien im Buch jedes Mal (wenn gespeichert wird) eine neue Version.

 

Meine Erfahrung sagt mir, eine wirkliche Top-Lösung die alles beherrscht von der Stange weg gibt es da nicht, weil Framemaker durch seine Programmierung und dem Verwalten von manchen Dingen per se für ein Versionskontrollsystem a la SVN massig neue Revisionen erzeugt. Mit Scripten kann man sicherlich noch was hinbiegen. Aber das muss dann halt wieder auf den individuellen Workflow angepasst werden.

 

Ich nutze SVN, dass ich überhaupt eine Versionkontrolle habe, aber glücklich bin ich damit nicht wirklich.

 

Soweit meine Erfahrungen zu SVN. Zu den anderen Lösungen wie SharePoint u. a. kann ich nichts sagen. Ich nutze auch keine XML, sondern nur .book und .fm

 

Grüße

M. Springer

 

 

Von: 'I. Burk' via frameusers-de <frameu...@googlegroups.com>

Gesendet: Montag, 31. Mai 2021 13:50
An: frameusers-de <frameu...@googlegroups.com>
Betreff: [frameusers-de] FrameMaker 2020: SharePoint 2013 als Repository?

 

Hallo zusammen,

--

[info]

Hallo,

bin mir nicht sicher, ob Sharepoint der richtige Ablageort für technische Dokumentation ist. Bezweifle das eher.

Deshalb haben wir bislang auch kein Projekt in diese Richtung gehabt, und ich kann zu den Probleme nichts sagen.

 

Wir gehen bei uns und in Projekten mehr und mehr den Weg über Github, Gitlab, Bitbucket. Entsprechende Clients zur Verwaltung sind in ausreichendem Maße vorhanden.

Wenn bereits vorhanden, könnte man das auch mit SVN lösen, würde ich aber nicht mehr neu einführen, sondern ob die oben genannten VCS setzen, da einfacher moderner und mehr Möglichkeiten hinsichtlich der Offline-(zusammen-)arbeit.

 

Grundsätzlich können dort auch problemlos binäre FM-Dokumente verwaltet werden. Besser ist es hier aber auf XML zusetzen. Änderungen in Binärdokumenten lassen sich beispielsweise nicht auf Dateiebene vergleichen (geht mit Sharepoint auch nicht), was mit XML problemlos möglich ist.

Wie gesagt FM-Binär-Dokumente ist nicht optimal, aber durchaus möglich. Würde persönlich aber diesen Weg und nicht den Sharepoint-Weg gehen.

 

Da in diesem Fall immer Offline gearbeitet wird, braucht es ein Konzept über die Ablagestruktur und ein spezielles Augenmerk, gerade bei der Arbeit mit binär-Dokumenten, auf externe Verweise wie Grafiken, Querverweise, Texteinschübe.

 

Hoffe das hilft weiter

Markus

 

 

Von: 'I. Burk' via frameusers-de <frameu...@googlegroups.com>
Gesendet: Montag, 31. Mai 2021 13:50
An: frameusers-de <frameu...@googlegroups.com>
Betreff: [frameusers-de] FrameMaker 2020: SharePoint 2013 als Repository?

 

Hallo zusammen,

--

[I. Burk]

Mit den Einschränkungen, dass ein Dokumentvergleich bei nativen FM-Dokumenten nicht direkt möglich ist, können wir leben.

Da ein Teil unserer Entwicklung GitHub oder ähnliches bereits nutzt, wäre das voraussichtlich kein größeres Problem.

Daher interessieren mich jetzt die praktischen Erfahrungen:

• Wieviel Aufwand ist es, GitHub für die Nutzung einzurichten? 
• Was müssen wir tun, um die Verwendung der Software für FrameMaker-Dateien hinzubekommen?

Das ist jetzt leider eine etwas unpräzise Frage, aber es wäre möglich, dass wir das eigenständig zum Laufen kriegen müssen.

Vielen Dank!

Iris Burk

[info]

Hi,

Da Ihr GitHub schon nutzt und Eure Entwickler damit bereits arbeiten, lade einen davon zum Kaffee ein, in dieser Zeit ist das repository eingerichtet und der Client installiert.

Dann braucht Ihr noch etwas Zeit und Erfahrung um damit zu arbeiten. Aber Deine Entwickler können Dir mit Sicherheit helfen und besten unterstützen.

Würde mal mit 0,5 Tag Einweisung rechnen und dann nochmal insgesamt 1 Tag, bis Ihr wisst, wie Ihr damit umgehen sollt.

 

Mit dem GIT-Client pushed Ihr Eure FM-Dokumente und Assets ins Repository. Etwas Verständnis, was ein commit, ein push, fetch und pull ist, ist das Minimum. Ggf. solltet Ihr mit Branches umgehen können.

 

Ihr habt das Know-how und die Tools im Haus.

Gruß

Markus

 

Von: 'I. Burk' via frameusers-de <frameu...@googlegroups.com>

Gesendet: Dienstag, 1. Juni 2021 17:53
An: frameusers-de <frameu...@googlegroups.com>

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/d325ea71-340a-4592-929d-d84b0b8d6a63n%40googlegroups.com auf.

[Johannes Graubner (Transcom)]

Hallo Markus,

 

> commit, ein push, fetch und pull

 

Übersetzt bedeutet das:

• Du holst die Dateien für die Bearbeitung von GitHub ins lokale Verzeichnissystem, bearbeitest sie und schiebst sie anschließend wieder zurück nach GitHub.
• Wenn in der Zeit jemand anderes an denselben Dateien arbeiten möchte, holt er/sie sich ebenfalls die Dateien, bearbeitet sie und schieb sie anschließend wieder zurück.
• GitHub nimmt beide Dateisätze als Zweige ins Repository
• Soweit dieselben Dateien betroffen sind, müssen beide (oder auch mehr) Zweige anschließend miteinander gemerged werden – bei Binärdateien (.fm) ein Ding der Unmöglichkeit, bei (alternativ) .mif-Dateien de facto ein Ding der Unmöglichkeit (wer kennt die MIF-Datenstruktur gut genug, um sicher einschätzen zu können, ob/wie Änderungen gemerged werden können?), und auch bei FM-XML-Dateien erscheinen mir gründliche Tests erforderlich, um abzusichern, dass das sinnvoll möglich ist

 

Ich vermute mal: Cloud/Repository geht mit .fm-Dateien nur, wenn die Dateien direkt von FM aus dem Repository geladen und derweil dort gelockt werden, so dass niemand sonst an den Dateien parallel arbeiten kann.

 

Oder übersehe ich hier etwas?

 

Viele Grüße

Johannes

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/AM0P189MB05969747FC83A35FFFB92310E03E9%40AM0P189MB0596.EURP189.PROD.OUTLOOK.COM auf.

[info]

Hi

Binärdateien lassen sich nicht sinnvoll vergleichen Und damit auch nicht mergen. Deshalb ist eine gleichzeitige (lokale) bearbeitung durch 2 Anwender über sperren oder organisatorisch zu regeln. 

Beim Mergen kann nur einer gewinnen. 

Wäre es meine Entscheidung würde ich in diesem Fall auf xml oder gleich DITA wechseln. Für offene Formate  ist VCS gemacht. Einen beitrag dazu gibts von mit in der letzten Tk oder auf unserem Blog https://blog.c-rex.net 

Gruss

Markus

Von meinem iPhone gesendet

Am 01.06.2021 um 23:15 schrieb Johannes Graubner (Transcom) <grau...@transcom.de>:



Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/005001d7572b%243acc3270%24b0649750%24%40transcom.de auf.

[I. Burk]

Hallo zusammen,

dass xml mit der Untermenge DITA einige Vorteile gerade im Bezug auf Versionskontrollsysteme hat, ist mir im Verlauf der Diskussion deutlich geworden. 

Allerdings gilt hierbei leider, dass theoretische Erkenntnisse erst mal in die Praxis umgesetzt werden müssen und dass "alles auf einmal" bei One-and-a-half-women-shows schlechterdings nicht möglich ist.

VSS ist nicht möglich, weil kostenpflichtig, nicht im Haus verfügbar und nicht mehr state of the art. Sofern mit VSS Visual Source Safe gemeint ist und nicht etwas anderes.

Besonderen Dank an Johannes, der die Entwickler-Schlagworte pragmatisch konkretisiert hat :)

Grüße

Iris

[info]

Hallo,

 

ich sagte nicht VSS (Visual Source Safe) sondern VCS (Version Control System), worunter moderne Systeme wie GIT, Bitbucket etc. fallen, und GIT hatte ich ja auch empfohlen, zumal von Euch schon eingesetzt.

 

Wie gesagt Binär geht grundsätzlich, mit ein paar Einschränkung, da eben kein offenes Format.

Viel Erfolg

Wenn Sie diese Diskussion im Web verfolgen möchten, rufen Sie https://groups.google.com/d/msgid/frameusers-de/1c5f312b-4422-4dc4-8912-bb73deaf92c7n%40googlegroups.com auf.

[I. Burk]

Ah, okay, dass ist mir im Eifer des konfektes entgangen ;)