Alfresco Share : Invitation fails …
Vor einigen Tagen habe ich neben unseren ganzen php-Applikationen auch unser “Gedächtnis” und gemeinsame Arbeitsplatform Alfresco auf unseren neuen Server umgezogen. Das ging auch prinzipiell alles ohne größere Schwierigkeiten von statten und war halt “nur” konzentrierte Fleißarbeit 
…
Lediglich ein Problem hatten wir danach : Wir konnten keine externen Benutzer (Kunden, Partner) mehr zu unseren Arbeitsbereichen auf Alfresco Share einladen. Es kam nur noch die Lightbox mit “Invitation failed” wo sonst immer stand “Invitation sent”.
Im folgenden einige Hintergrund-Informationen, die Diagnose und die Behebung des Problems. Nach meiner Recherche im Internet bei der Diagnose konnte ich mich des Eindrucks nicht erwehren, dass wir nicht die einzigen waren, die dieses Problem hatten oder noch haben 
… Diesen soll dieser Artikel eine Hilfestellung geben.
Um was geht es überhaupt hier ?
Zuerst einige Worte zu Alfresco, ein DMS oder besser ECM-System, das es als Opensource-Community-Version und als Enterpriseversion mit Support-Subscription gibt. Wir setzen die Communiy-Version ein, nebenbei bemerkt.
In einem anderen Artikel habe ich mich bereits lange und breit über DMS-Systeme im Allgemeinen und Alfresco im Besonderen ausgelassen : “Wozu eigentlich ein DMS ?”
In unserem besonderen Fall hier ging es um den Teil von Alfresco, der -ähnlich wie Microsoft Sharepoint- die Anlage von ad-hoc-Arbeitsbereichen mit wenigen Klicks ermöglicht. Danach hat man einen Bereich mit Wiki, Blogs, Foren, Kalender, Dokumentenablage etc …
Zu einem solchen Bereich kann man dann unter Angabe von Vorname, Nachname und Mailadresse externe Benutzer einladen. Diese erhalten dadurch eine automatisierte Einladungsmail mit Zugangsdaten und einem Link. Klicken sie dann drauf bekommen sie automatisch einen Account eingerichtet, mit dem sie nur für genau diesem Arbeitsbereich Zugang haben. Handy, isn’t it ?
Hier ein paar Screenshots um dies zu verdeutlichen:
Anlage eines Share-Arbeitsbereichs:
Share anlegen
Einladung verschicken:
Einladung verschicken
Das wäre es eigentlich schon …
Wir bekamen nach dem Umzug nur leider eine Lightbox mit der Mitteilung, dass die Einladung nicht funktioniert hat 
… fail …
Jetzt als kleiner Exkurs etwas zu unserer Serverhistorie:
Der Datenbestand unseres Alfresco wurde vor einigen Jahren mit der Version 2.1 erzeugt. Danach hatten wir mehrere Upgrades auf eine neue Version und auch bereits einmal einen Serverumzug. Das ging eigentlich immer problemlos und prinzipiell auch diesmal. Mit dem oben geschilderten kleinen “Schönheitsfehler” …
Unsere Version auf dem alten Server war die “Alfresco 3.0 Labs (stable)”. Die neue Version ist nun “Alfresco Community 3.2r2″. Also auch wieder ein Upgrade.
Kein Problem eigentlich:
- Alfresco-Tomcat-Bundle downloaden
- Entpacken
- Konfigurieren (ein File mit Einstellungen, übernommen vom alten Server und Pfade angepasst)
- Ordner Alf-Data (Dokumenten-Store und Suchindex) auf neuen Server kopieren
- Passende SQL-Datenbank ex- und hier importieren
- Starten
- Fertig
Geht eigentlich immer gut …
Auch diesmal :
- Zugriff per Webbrowser auf den Explorer-Zugang : geht
- Zugriff per Webbrowser auf Share-Zugang: geht
- Test von FTP und WebDAV : geht
- Einrichtung eines Test-Shares : geht
- Einladung eines externen Benutzers zu diesem Testhare : fail !!!
Jetzt war guter Rat teuer.
Zuerst schaut man mal ins Log-File. Was fanden wir da:
13:53:40,115 ERROR [org.alfresco.web.scripts.AbstractRuntime] Exception from executeScript – redirecting to status template error: 02020070 Wrapped Exception (with status template): 02020069 Failed to execute script ‘/org/alfresco/repository/site/invitation/invitation.post.json.js (in classpath store file:/srv/www/vhosts/human-touchnologies.de/subdomains/alfresco/httpdocs/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts)’: Non-unique path: found : /app:company_home/app:user_homes 0
org.alfresco.web.scripts.WebScriptException: 02020070 Wrapped Exception (with status template): 02020069 Failed to execute script ‘/org/alfresco/repository/site/invitation/invitation.post.json.js (in classpath store file:/srv/www/vhosts/human-touchnologies.de/subdomains/alfresco/httpdocs/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts)’: Non-unique path: found : /app:company_home/app:user_homes 0
at org.alfresco.web.scripts.AbstractWebScript.createStatusException(AbstractWebScript.java:613)
at org.alfresco.web.scripts.DeclarativeWebScript.execute(DeclarativeWebScript.java:165)
at org.alfresco.repo.web.scripts.RepositoryContainer$2.execute(RepositoryContainer.java:372)
at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:327)
at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecute(RepositoryContainer.java:422)
at org.alfresco.repo.web.scripts.RepositoryContainer.transactionedExecuteAs(RepositoryContainer.java:439)
at org.alfresco.repo.web.scripts.RepositoryContainer.executeScript(RepositoryContainer.java:303)
at org.alfresco.web.scripts.AbstractRuntime.executeScript(AbstractRuntime.java:306)
at org.alfresco.web.scripts.AbstractRuntime.executeScript(AbstractRuntime.java:183)
at org.alfresco.web.scripts.servlet.WebScriptServlet.service(WebScriptServlet.java:122)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
Das geht noch seitenweise so weiter . Ist halt J2E mit Java-Beans. Schaut immer so aus bei dieser Umgebung … Der eigentliche Fehler ist aber der orange markierte …
Längeres Meditieren und eine längere Suche im Internet und hier vor allem auch in den Support-Foren der Community brachte folgende Erkenntnis :
Irgendwas stimmt nicht mit dem System-Bereich, in dem die “Home Spaces” der User automatisch angelegt werden. Also was tut man in einem solchen Fall ? Man überprüft und man macht das am besten in dem man mit einer funktionierenden Installation vergleicht.
Gesagt getan : Ich habe eine Parallel-Installation von Alfresco aufgesetzt. Dabei muss man aber beachten, dass es zwischen den beiden Installationen keine Port-Konfikte gibt !!
Produktivinstallation war standardmäßig (wie bei Tomcat so üblich) auf Port 8080 eingerichtet. Zugang mittels http:<server>:8080/alfresco
Die neue sollte also auf Port 8181 hören. Hier hat mir ein Blog-Artikel geholfen, da ich sonst sicher länger gebraucht hätte : http://www.jb-networks.com Hab mich auch schön bedankt, wie es sich gehört ! Mit Hilfe dieses Artikels war die Parallel-Installation jedenfalls kein Hexenwerk mehr.
Mit Hilfe dieser Referenz-Installation konnte ich mich jetzt vergleichend durch das Schema wühlen und tatsächlich, es gab einen Unterschied : Der Bereich “User Homes” war kein Systembereich mehr. Damit war er auch nicht mehr wie ein Systembereich im Code zu adressieren. Die Fehlermeldung oben war also eigentlich logisch ! Der Code fand seinen Bereich nicht mehr, in dem er den Homespace anlegen wollte, sollte …
Mit dieser Erkenntnis konnte ich mich jetzt auf die Suche nach einer Lösung machen :
Der eigentliche Grund für dieses Problem war bald gefunden : In früheren Versionen war ein Bug versteckt, der bei Umbenennung dieses Bereichs genau diese Änderung herbeiführt. Gab mit den alten Versionen da zwar kein Problem, aber bei der neuen Version klappts nicht mehr. Wir sind sozusagen Leidtragender einer langen Versionshistorie. Also reparieren …
1. Ansatz: ein Workaround aus der Bug-Datenbank
Mit Hilfe einiger sehr nachvollziehbarer SQL-Statements sollte man diesen “user_home”-Homebereich wieder zu einem System-Bereich machen können. Also Backup, Tomcat-Cache löschen, SQL bearbeiten und ausprobieren …
Leider nur ein halber Erfolg ! Es war alles gut, bis auf die Adressierung über xpath. Die gesamte Datenstruktur schien jetzt zu passen und stimmte mit der Referenz-Installation überein. Aber die Suche nach /app:company_home/app:% im NodeBrowser listete meinen Bereich immer noch nicht. Mist … Einladungen gingen natürlich damit immer noch nicht …
2. Ansatz : Export des Systembereichs “User Home” von der Referenzinstallation und Import auf unserem Produktivsystem. Vorher natürlich mal wieder umbenennen. Klar …
.
.
.
.
BINGO ! Das hat geklappt !
- xpath-Suche listete meinen Bereich ordungsgemäß auf
- Test der Einladung klappt auch !
Mein Problem ist also endlich gelöst und ich hoffe ich kann mit dieser Lösung auch anderen helfen.
Ich glaube ich muß nicht erwähnen, dass mich diese Fehlersuche tagelang beschäftigt hat. Nicht durchgehend, aber immer wieder. Beim nächsten mal gehts schneller …
