InfoPath – Doppelte Felder nach der Neuveröffentlichung in SharePoint
avatar

Während eines internen Projektes bei der HanseVision trat kürzlich ein Phänomen auf, das ich bereits aus vorherigen Projekten kannte: Nach der erneuten Veröffentlichung eines InfoPath-Formulars in SharePoint (2007 oder 2010) verdoppeln sich die publizierten Spalten. Daher jetzt die Motivation, meine Erkenntnisse in diesem Blog-Eintrag niederzuschreiben. Dieser Blog-Eintrag simuliert den Fehler, zeigt den Grund für das Verhalten und skizziert einen Lösungsansatz.

 

Als Software-Entwickler entwickelt und testet man in der Regel in einer eigenen Entwicklungsumgebung und nicht am offenen Herzen (Live-System). Dies gilt auch für InfoPath-Formulare! Und genau hier scheint das Problem zu liegen!!!

Um diesen Fehler reproduzieren zu können, habe ich folgendes Szenario durchlaufen:

Ich habe ein ganz einfaches InfoPath Formular erstellt und in einer SharePoint Site Collection (“info2”) als Inhaltstype veröffentlicht. “Info2” soll meine Entwicklungs- bzw. Testumgebung simulieren.

image

Bei der Veröffentlichung habe ich drei Felder meines Formulars als neue SharePoint-Felder definiert.

image

 

Nach der Veröffentlichung habe ich in der SharePoint Site Collection “info2” eine InfoPath Form-Bibliothek angelegt, den gerade erstellten Inhaltstyp zugewiesen und die Standard-Sicht um die publizierten Felder erweitert. Soweit alles perfekt!

image

 

Dann habe ich das InfoPath-Formular minimal angepasst und erneut auf “info2” veröffentlicht. (Diesmal habe ich einen anderen Ort für die Vorlage ausgewählt).

image

Die zu publizierenden Felder habe unangepasst gelassen.

image

 

Ein Blick auf die Einstellungsseite der InfoPath-Form-Bibliothek zeigt, dass nach direkter Neuveröffentlichung alles in Ordnung ist! Keine Doppelten Spalten!

image

Auch die Spalten des Inhaltstyps werden in der Liste richtig mit den Formular-Daten verknüpft.

image

 

Doppelte Spalten erzeugen:

Nach der Neuveröffentlichung habe ich etwas gemacht, was man in jedem reellen Projekt auch machen würde. Ich habe das funktionierende und getestete InfoPath-Formular auf einer SharePoint-Site Collection “info1” (http://win-4nc91p2lp59/sites/info1/) veröffentlicht. Dies soll mein Live-System darstellen.  Analog zu “info2” habe ich eine InfoPath-Form-Bibliothek angelegt und den erstellten Inhaltstype zugewiesen. Bis dahin war alles wie es sein sollte!

 

Nun habe ich eine Formular-Erweiterung simuliert, die in fast jedem Projekt auftreten kann. Ich habe demnach das “Live-veröffentlichte” Formular wieder im Bearbeitungs-Modus geöffnet und Felder ergänzt.

image

Nach dem Hinzufügen der neuen Felder habe ich das Formular wieder auf meinem Test-System “info2” veröffentlicht, um die Änderungen zu testen.

image

Also habe ich den bereits bestehenden Inhaltstyp selektiert, um diesen zu aktualisieren.

image

 

Bei den zu publizierenden Spalten habe ich die neue hinzugefügt und anschließend die Veröffentlichung abgeschlossen.

image

 

Ein schneller Blick in die Einstellungsseite der InfoPath Form-Bibliothek im SharePoint zeigt, dass nun ein Problem aufgetreten ist. Auf einmal sind doppelte Spalten vorhanden!

image

Dadurch entsteht ein echtes Problem! Die InfoPath-Feldinhalte werden nun auf die neuen Spalten verknüpft. In den bestehenden SharePoint-Sichten und ggf. diversen anderen Erweiterungen (bspw. Webparts) sind allerdings die alten Spalten verknüpft! Wenn nun bereits sehr viele Dokumente mit der alten Formularversion bestehen, kann man den korrupten Inhaltstype nicht einmal entfernen, da dieser noch verwendet wird! In diesem Fall kann nur das Einspielen eines Backups helfen oder ein sehr aufwändiger Prozess, in dem alle Dokumente einen neuen, temporären Inhaltstyp bekommen und der korrupte somit gelöscht werden kann. Es kann sogar erforderlich sein, dass die komplette InfoPath-Form-Bibliothek neu angelegt werden muss, um die doppelten Felder zu entfernen.

Aber was ist da gerade passiert?!

Das Problem besteht in der parallelen Veröffentlichung des Formulars! Nachdem ich das Formular auf http://win-4nc91p2lp59/sites/info2 erstmalig veröffentlicht habe, wurden im InfoPath Formular die SharePoint Spalten-IDs referenziert und die Verknüpfung intern abgespeichert, damit bei einer Neuveröffentlichung die SharePoint-Felder wieder gefunden wurden. Diese Verknüpfung zwischen InfoPath- und SharePoint-Feld kann in der manifest.xsf (XSN als CAB-File umbenennen und öffnen) eingesehen werden. Die SharePoint-Feld-ID ist nachfolgend rot unterstrichen.

image

Wenn nun das selbe InfoPath-Formular auf der URL http://win-4nc91p2lp59/sites/info1  (bspw. dem Live-System) veröffentlicht wird, werden dort neue SharePoint-Spalten angelegt und referenziert, weil die SharePoint-Feld-IDs von “info2” hier nicht gefunden werden können. Öffnet man nun die manifest.xsf nach dem Veröffentlichen auf “info1”, dann ist ersichtlich, dass die oben markierte SharePoint-Feld-ID nun eine neue ist. (vorher „5856e…“ und nun „ce97…“)

image

Das eigentliche Problem entsteht nun die erneute Veröffentlichung auf der Test-Website http://win-4nc91p2lp59/sites/info2, da durch die Veröffentlichung auf “info1” der Bezug zur ursprünglichen Spalte mit der ID „5856e…“ verloren gegangen ist. InfoPath findet nun das referenzierte Feld nicht und erstellt eiskalt ein neues Feld mit neuer ID.

image

Aus diesem Grund entstehen die doppelten Spalten, da die SharePoint-Feld-Referenzen verloren gehen!!!. So entsteht eine Art Pingpong-Effekt zwischen den beiden Veröffentlichungs-Systemen.

Lösung:

Anscheinend ist es von InfoPath vorgesehen, dass man für jedes System, auf das man veröffentlicht, eine eigene XSN-Datei (Formular-Vorlage) erzeugen muss. Unterm Strich würde es in einer Umgebung mit Test-System bedeuten, dass man die Formular-Änderung in zwei Formularen parallel durchführen muss. Das kann nicht der Sinn einer Testumgebung sein, oder?

Die einzige Möglichkeit mit nur einem InfoPath-Formular auf zwei Systemen zu arbeiten, ist das abgleichen der Spalten-ID in der manifest.xsf für das jeweilige System. Diesen Schritt von Hand durchzuführen ist allerdings sehr aufwändig und zudem fehleranfällig! Aus diesem Grund habe ich eine schlanke .Net Applikation entwickelt, die diesen Abgleich für mich etwas erleichtert.

 

Vorgehen ID-Abgleich:

Schritt 1: Das Formular als Quelldateien exportieren, um schreibend auf die manifest.xsf zugreifen zu können.

image

Nach dem exportieren liegen die Quelldateien des Formulars in dem ausgewählten Verzeichnis offen.

image

 

Schritt 2: Die bereits auf dem System publizierte InfoPath Vorlage herunterladen, in .cab umbenennen und die manifest.xsf extrahieren

image

Nach dem Umbenenne der XSN-Datei in .CAB kann die manifest.xsf extrahiert werden. In dieser Manifest.xsf stehen die für das Ziel-System gültigen SharePoint-Feld-IDs. Diese können jetzt genutzt werden, um sie in unser neues, “als Quelldateien exportiertes” Formular zu überführen.

image

Um die IDs abzugleichen habe ich eine schlanke Applikation entwickelt, die mit Hilfe beider XSF-Dateien einen SharePoint-Feld-ID-Abgleich durchführt.

image

Dieser Code ersetzt die SharePoint-Feld-IDs des neu zu veröffentlichen Formulars mit denen der bereits veröffentlichten Formular-Version.

 /// <summary>
        /// Smooth the new form manifest ids using the published manifest
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        private void buttonSmooth_Click(object sender, EventArgs e)
        {

            XDocument oldXsf = XDocument.Load(textBoxPublishedXsf.Text);
            XDocument newXsf = XDocument.Load(textBoxNewXsf.Text);
            var pubResults = oldXsf.Descendants("{http://schemas.microsoft.com/office/infopath/2006/solutionDefinition/extensions}fieldExtension");
            var newResults = newXsf.Descendants("{http://schemas.microsoft.com/office/infopath/2006/solutionDefinition/extensions}fieldExtension");

            //for every published field in the published form
            foreach (var oldResult in pubResults)
            {
                //iterate through the new forms publishing fields 
                foreach (var newResult in newResults)
                {
                    //if one field matches the old form field, then assing the old SharePoint field id to the new form
                    if (oldResult.Attribute("columnName").Value.Equals(newResult.Attribute("columnName").Value,StringComparison.InvariantCultureIgnoreCase))
                    {
                        newResult.Attribute("columnId").Value = oldResult.Attribute("columnId").Value;
                        break;
                    }
                }
            }
            // save the new manifest.xsf 
            newXsf.Save(textBoxNewXsf.Text);
        }

 

Nachdem die manifest.xsf angepasst wurde, kann das neue Formular wieder im Entwurfsmodus geöffnet und anschließen veröffentlicht werden.

image

Nach dem Öffnen lege ich gerne das neue InfoPath-Formular (Quelldateien) als neue Version im XSN-Format ab.

image

Nach dem ID-Abgleich und der Veröffentlichung kann man in den SharePoint-Listen-Einstellungen sehen, dass sich die publizierten Felder nun nicht verdoppelt haben.InfoPath konnte die Verknüpfung der Felder korrekt durchführen.

image

 

Ich hoffe dieser Beitrag kann all jenen helfen, die sich ebenfalls über das Doppelte-Felder-Phänomen gewundert haben.

Ein Gedanke zu “InfoPath – Doppelte Felder nach der Neuveröffentlichung in SharePoint
avatar

  1. Auch nicht schlecht. Eine andere Möglichkeit ist die betroffenen Spalten einmalig via Feature als Websitespalten zu deployen. Dann bleibt die ID gleich und das Phänomen tritt nicht auf.

Schreibe einen Kommentar