Naturally, every company wants to keep their internal document management system as secure as possible and on premise systems are rarely opened up to the internet or even VPNs used by external partners.

With the latest version 4.1 Alfresco has introduced a Cloud Sync capability, which allows users of an on premise Alfresco Enterprise system to make documents available in the Alfresco Cloud and allow synchronization of changes in both directions. This enables the users to collaborate on select documents with external partners while business critical and confidential documents stay securely in the on premise document management system.

One use case where this synchronization with the cloud is compelling, is the collaboration with external partners or contractors. Imagine a production planning department that is working on a technical specification document for a product in their local Alfresco collaboration system. They use a site for that planning project in Alfresco Share to collaborate within the team.

When a first version of the specification with supporting documents is complete, it is stored in a folder and it needs to be shared with an external supplier who might produce some of the parts for the product. As in many companies, the local Alfresco system must not be connected to the internet for security reasons and therefore the supplier will not be able to easily access the documents.

Until now this might have been the moment where a team member would resort to sending the specification documents to the supplier via email – but now there is a more elegant solution. Using the cloud synchronization feature from Alfresco 4.1 the planning team now can share the documents using the Alfresco Cloud and keep both places in sync. The team creates a new site in the Alfresco Cloud and invites the contacts from the supplier. The only information that is needed are the email addresses:

The planning team can now share the specification to the cloud server using the new sync to cloud actions in Alfresco.

They only need to create and select a target folder from the cloud system where the documents should be uploaded.

The complete folder with the specification and the supporting documents is copied to the cloud. The new documents appear in the cloud’s site document dashlet where the supplier contacts can see that new documents have been uploaded.

Since the specification is a Word document the supplier can open the document, edit it and add annotations to it. As usual version tracking is enabled and all changes are stored as new versions.

The changes that the supplier made to the specification are sync’ed back to the on premise server and are available as a new version of the document. The version history shows from which site and folder in the cloud the document was imported.

The changes in the cloud are reflected in a new version.

The my documents dashlet informs the internal team members that the specification document has been updated. To clarify some of questions that the supplier had, a planning team member uploads a draft of the product design to the shared folder. This new document is picked up by the cloud sync as well and is automatically made available to the supplier team, who are using the Alfresco Cloud.

This concludes this small collaboration example. Of cause it would also be possible for the supplier team to upload new documents the the cloud and have those synchronized to the on premise Alfresco system. This example shows some of the benefits of having the same technology (Alfresco Share) on both sides of the firewall and having documents synchronized seamlessly between them.

The capabilities of the cloud sync will be extended further and will most likely allow the synchronization of custom metadata in the future. Cloud sync will become even more powerful when factoring in that documents in the cloud can be easily accessed by Alfresco mobile apps (iOS, soon Android) and the Desktop Sync client as well, that will allow file synchronization similar to the popular DropBox client. All these technologies help to make documents available wherever you need them while keeping all the places in sync.

Während meines Studiums in den 80er Jahren waren Mainframes/Hosts mit 3270er Terminals angesagt. Das Pendel hing also beim Server.

Als in den 90er Jahren die PCs dank Intel-486 immer leistungsfähiger wurden und durch sinkende Preise weite Verbreitung fanden, schwang das Pendel zur Client-Seite. Anwendungen wurden typischerweise als Fat-Clients gebaut.

Doch dann der Zoo genutzter Windows-Client-Plattformen zur Jahrtausendwende: 95, 98, ME, 2000, NT mit diversen Service-Packs. Die Client-Anwendungen waren sehr empfindlich… Stichwort DLL-Hölle. Das Pendel schwang wieder zurück zum Server, Web-Applikationen im Browser waren angesagt… bis die vielen Seitenladevorgänge wieder die Suche nach etwas Neuem anstießen.

Um also die Kommunikation zwischen Web-Applikation und Server zu optimieren, wurden Techniken wie Applets, Ajax u.a. eingesetzt, um doch wieder mehr Programmlogik auf dem Client auszuführen. Wieder schwang das Pendel… nun hängt es beim Client, so sehe ich den heutigen Stand.

Wo wird die Reise hingehen?

Ich denke, dass Sicherheitsaspekte das Pendel (…zumindest zum Teil) wieder zum Server zurückschicken werden.

Es ist zu einfach, auf dem Client laufende Applikationen zu untersuchen und zu verändern. Bei Ajax im InternetExplorer reicht bereits F12 („Entwicklertools“), um den gerade laufenden Javascript-Code zu debuggen und zur Laufzeit zu verändern; und für Firefox gibt es Firebug.

Signierte Java-Applets verändert einzusetzen ist zwar schwieriger, aber mit De-Compile und einem selbst kompilierten Bowser (mit abgeschalteten Sicherheitsmechanismen) auch möglich. (Bekannte gezielte Attacken wie Phishing, Cross-Site-Scripting u.ä. zum Stehlen von Logins/Sessions möchte ich hier nicht weiter betrachten.)

Mit den genannten Tools könnten Prüfungen und Verbote von Funktionsaufrufen umgangen werden. Daher sehe ich eine Notwendigkeit zur Verbesserung von Sicherheit in Anwendungen durch Mechanismen auf den Servern.

Dies ist z.B. beim Documentum Content Server der Fall, wo im Backend alle Ordner und Dokumente durch Zugriffsrechte geschützt und die Benutzer nur zugeordnete Privilegien/Funktionsrechte besitzen. Mit den o.g. Tricks könnten dann evtl. zwar Plausibilitätsprüfungen im Client umgangen werden, aber ein unberechtigter Zugriff auf geschützte Dokumente wird nicht möglich.

Greift die Client-Applikation aber auf einfache Datenbanktabellen ohne weitere Sicherungsmechanismen zu, so sind Tür und Tor weit geöffnet…

Einen möglichen Lösungsansatz zur Absicherung der Client-Server-Kommunikation sehe ich dann z.B. darin, dass die vom Server gelieferte Webseite die „Tokens“ für erlaubte Funktionsaufrufe enthält. Das können z.B. verschlüsselte Kombinationen aus Benutzerkennung, Zeitstempel, ObjektID und Funktionsname sein. Änderungen in den Eigenschaften eines Objektes werden an Server/Datenbank übermittelt, als Antwort gibt es neue Tokens entsprechend den nun erlaubten Funktionen. Damit wären manipulierte Funktionsaufrufe für den Server erkennbar.

Vielleicht wird es aber auch ganz andere Techniken für die Client-Programmierung geben, um gegen lokale Programmveränderungen zu schützen. Ich bin sehr gespannt, welche Frameworks sich für diese Aufgabe etablieren werden, welche Technik/Architektur sich durchsetzen und wo das Pendel in Zukunft hängen wird…

Nur ein Pendel, aber es bleibt spannend.

Basierend auf dieser Ausgangsituation wurde in der fme AG ein Service entwickelt und eingerichtet, der dem Benutzer erlaubt, Dokumente per E-Mail aus dem DMS abzurufen. Dieser Service setzt im Wesentlichen vier Anforderungen voraus:

• eine Verbindung des E-Mail-Clients zum Mail-Server der Firma
• ein Postfach, das die Anfragen entgegennimmt
• ein Dokument muss eindeutig identifiziert werden können
• Zugriffsrechte auf das benötigte Dokument

Sind diese Kriterien erfüllt, gestaltet sich das Arbeiten mit diesem Service für den Anwender als sehr einfach. Es genügt, wenn der Anwender eine neue E-Mail erstellt und als Empfänger das Postfach angibt, welches die Anfragen entgegennimmt und im Betreff der E-Mail einen Wert einträgt, der das Dokument eindeutig identifiziert. Die fme verwendet hierfür eine im System einmalig vergebene Dokumenten-Nummer im DMS. Dabei handelt es sich um ein eigens von fme programmiertes Add-on im Documentum Webtop von EMC. Mit dem Abschicken der E-Mail ist die Arbeit für den Anwender erledigt, und er muss lediglich kurz auf die Antwort abwarten.

Dieser DMS-E-Mail Service nimmt die Anfragen entgegen und prüft zuerst, ob der Benutzer berechtigt ist, Zugang zum Firmennetzwerk zu erhalten. Ist dies der Fall, wird anschließend das angeforderte Dokument mitsamt der erteilten Berechtigungen aus dem DMS abgerufen. Verfügt der Benutzer mindestens über die Berechtigung, das Dokument zu lesen, erhält er eine Kopie dieses Dokuments und Informationen per E-Mail. Damit ist der Vorgang abgeschlossen.

Automatisch generierte E-Mail mit dem gewünschten Dokument

Der Service macht sich die Funktionalität des E-Mail-Clients zu Nutzen, abgebrochene Downloads ohne neue Aufforderung fortzusetzen. Der E-Mail-Client lädt das Dokument bzw. Teile des Dokumentes herunter sobald eine Verbindung zum Server besteht.

Diese Vorgehensweise bringt weitere Vorteile mit sich:

• Bei passender Konfiguration des E-Mail-Clients ist das Dokument auch offline verfügbar
• Das Dokument ist auf allen Geräten verfügbar auf denen das E-Mail-Konto eingerichtet ist – vor allem sehr hilfreich, um mit mobilen Endgeräten Dokumente abzurufen

Für die Sicherheit der Übertragung sorgt die Art der Verbindung. Beispielsweise ist die Verbindung von Outlook per VPN-Verbindung realisierbar und auch der Web-Access von Outlook ist geschützt, da dieser über https kommuniziert. Die einzige Einschränkung ist die maximale Dateigröße, die der jeweilige Mail-Server zulässt.

Das interne Feedback bei fme zu dem “DMS-E-Mail-Job” war sehr positiv und reichte von “I love it”, über “Finally! For me (working externally) that’s really a long wanted feature. Thanks!!” bis hin zu “Triple like!” und “It´s so great to use this job in the train ;-)”. Das motiviert natürlich zu weiteren Add-ons, die helfen die tägliche Arbeit mit einem DMS zu verbessern.

Den Anstoß gab ein Kundenprojekt: hier wurde die smartBar als reiner Such-Client ursprünglich eingesetzt. Dieser Such-Client wurde in eine iPad App portiert mit folgenden grundlegenden Funktionalitäten:

- Suche nach Dokumenten: Über die App lassen sich Dokumente im Repository suchen. Die Suchmaske orientiert sich dabei an der Desktop-smartBar.

- Browsen im Repository: in einer zweiten Ansicht kann man durch die Ordner navigieren, um die benötigten Informationen zu finden.

- Dokumente lassen sich direkt über die App öffnen und ansehen.

- Offlinefunktionalität: Dokumente lassen sich einfach offline verfügbar machen, so dass man auch ohne Zugriff auf das Repository auf die Informationen zugreifen kann.

Suchfunktionalität

Die Suchfunktionalitäten wurden weitestgehend von der smartBar übernommen: Es kann im Volltext oder in Attributen gesucht werden, und die Suche kann auf Dokumenttypen eingeschränkt werden. Für Attribute mit hinterlegten Wertelisten werden diese in der App ebenfalls angezeigt. Für die Suche nach Datumswerten, wie Erstellungs-/Änderungsdatum und auch nach spezifischen eigenen Datumsfeldern können Datumsintervalle eingestellt werden.

 Mobile smartBar-Suche mit Ergebnisliste

Gespeicherte Suchen

Die Kriterien einer Suchanfrage können auf dem iPad abgespeichert werden. So ist es möglich, eine einmal konfigurierte Suche jederzeit wieder auszuführen ohne alle Kriterien erneut einzustellen.

Filter

Das Ergebnis einer Suchanfrage lässt sich dreistufig mittels Filter eingrenzen, um schneller zum gewünschten Dokument zu gelangen. Für jeden Filter wählt der Benutzer ein Attribut aus und bekommt die Wertemenge des Attributs angezeigt. Durch Auswahl eines Wertes lässt sich das Suchergebnis immer weiter einschränken.

Dokumentenansicht

Jedes Dokument kann in der Vorschau- und Vollbildansicht betrachtet werden. In der Vorschauansicht kann der Benutzer sich die Attributierung des Dokuments ansehen und auch bereits einen Blick auf den Inhalt werfen. Die App unterstützt die Anzeige von Dokumenten über Apples WebView-Komponente und kann somit Dokumente in den Formaten PDF öffnen sowie die gängigen Standard-Office- und Bildformate.

Aber auch die Ansicht von Dokumenten, die nicht von der WebView unterstützt werden, ist realisierbar. In der ersten Version wurde bereits ein eigener Viewer für das E-Mail-Format MSG umgesetzt, damit diese über die App angezeigt werden können.

Ergebnisliste mit Vorschaufunktion

Browsen im Repository

Auch die einfache Navigation durch die Ordner im Repository ist möglich. Hier stehen die gleichen Funktionen wie in der Suchansicht zur Verfügung: das Filtern eines Ordnerinhalts ist ebenso möglich wie die Ansicht von Dokumenteninhalten und –attributen.

Offline-Funktionalität

Benutzer der App können Dokumente offline verfügbar machen. Diese lokal abgelegten Dokumente werden im nichtflüchtigen Speicher des iPads verschlüsselt abgelegt und sind nur für den smartBar-Client ersichtlich und erreichbar. Wie bei den aus dem Repository angezeigten Dokumenten besteht keine Möglichkeit, diese Dokumente z.B. in einer anderen App zu verwenden oder sie per Mail zu verschicken.

Performanz

Bei der Nutzung von internen Funktionalitäten der App (Betrachten von lokalen Dokumenten, Eingabe von Suchbegriffen) und auch bei der Suche selbst, beim Laden und Anzeigen von Dokumenten wurde eine hohe Performanz angestrebt. Die Geschwindigkeit ist allerdings abhängig von der Netzwerkgeschwindigkeit, dem Webservice und des Repositories.

Sicherheit

Beim Start der Applikation muss sich der Benutzer mit seinem DMS-Login anmelden. Auch im Offlinebetrieb ist dies notwendig, um die auf das iPad heruntergeladenen Dokumente zu schützen. Dazu wird ein sog. Fingerprint des Passworts (SHA256 Hash) auf dem Gerät gespeichert. Der Abruf der Daten und Dokumente erfolgt, wie von der smartBar bekannt, über einen Webservice – derzeit noch unverschlüsselt. Um die Sicherheit beim DMS-Zugriff zu erhöhen, kann der Kommunikationsweg über eine VPN-Verbindung verschlüsselt werden.

Über die App abgerufene Dokumente lassen sich nur innerhalb der App anschauen. Eine Weitergabe an andere Apps, z.B. das Versenden des Dokuments per E-Mail wurden aus Sicherheitsgründen unterbunden. Dokumente, die für die Offline-Verfügbarkeit lokal gespeichert werden, werden verschlüsselt (mit AES256) abgelegt. Auch hier ist sichergestellt, dass sie nur innerhalb der App verwendet werden können.

Entwicklungsplattform

Vor Beginn der Entwicklung wurden verschiedene Alternativen für die Umsetzung betrachtet. Zur Auswahl standen native Implementierungen für einzelne mobile Endgeräte, hybride Ansätze, wie PhoneGap, um verschiedene Endgeräte unterstützen zu können oder auch eine HTML5-basierende Lösung.

Letztlich wurde eine Implementierung nativ für das Apple iPad durchgeführt, da diese Lösung in Sachen Bedienung, Performanz, Leistungsumfang und Stabilität am besten geeignet schien und derzeit nur das iPad als Zielplattform angedacht ist.

Schnittstellenkonzept

Der smartBar Client bedient sich dem schon durch die smartBar vorhandenen Webservice. Der Client nutzt SOAP als Nachrichtenformat und verarbeitet die Ergebnisse des Funktionsaufrufes zur Darstellung für den Nutzer. Die App nutzt auch die Konfigurationsmöglichkeiten der Original-smartBar und teilt sich die Einstellungen mit dieser. Die verfügbaren Dokumenttypen in der Suche inklusive der Konfiguration der typspezifischen Suchmaske, die Auswahl der Filterattribute und auch die Spaltenkonfiguration der Ergebnisliste werden über die vorhandene smartBar-Administrationsoberfläche eingestellt.

App Architektur

Die App wird ARC und das Storyboard Konzept verwenden, was auf iOS 5.0 aufbaut. In der App werden die Einstellungen von User, Repository und Webservice-URL in den iOS Einstellungen vorgenommen.

Grundlage der App ist eine klassische 3-Tier-Architektur (Data – Business – UI). Dies gewährleistet eine hohe Wiederverwendbarkeit, gute Wartbarkeit und Erweiterbarkeit. So ist es z.B. relativ einfach möglich, die Datenzugriffsschicht der App auszutauschen und gegen eine Alternative zu ersetzen, die den Zugriff statt über den smartBar-Webservice beispielsweise über eine CMIS-Schnittstelle realisiert.

Das matrixbasierte Konfigurationsinterface stellt alle elementaren Aspekte der EMC Documentum Plattform bereit, die anschließend dem Endbenutzer in einer modernen browserbasierten Rich Internet Client Anwendung zur Verfügung stehen. Dadurch können erstmals ECM Projekte agil mit starker Einbeziehung des Kunden durchgeführt werden.

Ein weiterer Vorteil der Konfiguration liegt in der deutlichen Kostenreduzierung von Projekten, da aufwendige Anpassungen durch Programmierer entfallen, die bisher Kostentreiber in Projekten waren. Das Deployment von fertig konfigurierten Anwendungen geschieht über einfache Import- und Export-Funktionen, die das Konfigurationsinterface anbietet und somit die Übernahme von Integrationssystemen auf Produktivsysteme oder die generelle Bereitstellung von Anwendungen in wenigen Minuten zulässt.

Die Technologie des Documentum D2 Clients wurde von dem französischen Software-Anbieter C6, mit dem fme schon seit 2010 eine Technologiepartnerschaft einging, zugekauft. Vor der Akquise durch EMC Documentum hat C6  ihr Produkt D2 über mehrere Jahre erfolgreich vertrieben.

fme hat Kunden bei der Auswahl einer ideal an deren Bedürfnisse angepassten ECM-Schnittstelle begleitet und auf diese Weise bei der Implementierung von D2 unterstützt – wie auch in seiner Erweiterung und Integration. In erster Linie überzeugen die Konfigurationsmöglichkeiten, da diese tatsächlich die Anpassung des Systemverhaltens an die Eigenheiten und Bedürfnisse jeder einzelnen Verwaltung und Organisation erlauben und gleichzeitig eine einheitliche ECM-Funktionalität sowie organisationsübergreifende Arbeitsabläufe und entsprechenden Informationsaustausch ermöglichen.

Konfigurierbare Funktionen:

• Konfigurierbare Client-Oberfläche für Menüeintrage, Navigationsbaumelemente und UI-Style

• Konfiguration von komplexen Eigenschaften- und Suchdialogen

• Erstellung von Taxonomien z.B. für die Klassifizierung von Dokumenten

• Unterstützung von Workflows und Lifecycles

• Drag & Drop Unterstützung mit konfigurierbaren Importdialogen

• und weitere

Vorteile:

• Moderne und intuitive Browser Oberfläche

• Client-Funktionen werden konfiguriert – dadurch werden lange und teure Entwicklungen vermieden

Seien Sie gespannt auf die Fortsetzung dieses Blog-Artikels, der sich mit der neuen Documentum D2 Version 4.0 beschäftigt.

Zurzeit können Workflowprozesse innerhalb des xft contract managers über die SAP-GUI oder einer SAP-Webkomponente ausgeführt werden. In Zusammenarbeit mit der Hochschule Augsburg und im Rahmen einer Projekt- und einer Bachelorarbeit wurde eine neue Möglichkeit geschaffen, die Workflowaufgaben auf mobilen Endgeräten abzubilden. Mit der Integration einer mobilen Lösung bietet man Unternehmen die Möglichkeit an, auch externe Mitarbeiter in die Geschäftsprozesse des Unternehmens zeitnah mit einzubinden.

Es ermöglicht externen Nutzern die Aufgaben, die im xft contract manager  anfallen, unterwegs und ohne Verbindung zum Unternehmensnetzwerk, auszuführen. Das Ergebnis kann nach Ausführung der Aufgabe, z.B. mittels einer VPN-Verbindung, wieder direkt an das SAP-System übermittelt werden. Die Lösung bringt einen erheblichen Zeitvorteil mit sich, da der Anwender, unabhängig seines Aufenthaltsortes, die Aufgaben zu jedem Zeitpunkt ausführen kann. Exemplarisch wurde dies an einer Aufgabe des Genehmigungsprozesses im Vertragsmanagements durchgeführt, bei der ein Workflowprozess wartet, bis der zuständige Anwender eine Entscheidung fällt bzw. das mobile Endgerät das Ergebnis der Genehmigung wieder an das SAP-System übergibt.

Um einen Daten- und Dokumentenaustausch zwischen SAP und mobilen Endgeräten zu ermöglichen, wurde eine Schnittstelle zwischen SAP und den mobilen Geräten realisiert und sowohl auf Basis von Apple iOS als auch auf Basis von Android ein Prototyp zu erstellt, der Daten und elektronische Dokumente in einem Workflowaufgabenschritt aus dem xft contract manager oder aber aus einem Standard SAP Business Workflow heraus anzeigen kann. Dabei wurde explizit die Möglichkeit einer „offline“-Verarbeitung berücksichtigt. Der Anwender kann somit zu jedem Zeitpunkt, unabhängig zur Verbindung zum Unternehmensnetzwerk seine Aufgaben zur Genehmigung bearbeiten.

Daten- und Dokumentenübertragung am Beispiel von Android

Als mobile Endgeräte eignen sich vor allem Tablet-PCs, da diese gegenüber Notebooks handlicher sind und im Vergleich zu Smartphones ein größeres Display bieten.

Screenshot: Prototyp der Vertragsgenehmigung auf einem Android-System

Die fme AG ist jetzt in der Lage sowohl für die Plattform iOS als auch für die Plattform Android Genehmigungsprozesse, die in SAP über SAP Business Workflow angestartet worden sind auf mobile Endgeräte mitsamt der zugehörigen Dokumente und Metadaten zur Offline-Verarbeitung zu übertragen.

Rechnungsgenemigung auf einem Apple iPad

1 Installation/Deployment

The EMC CMIS implementation for Documentum is implemented as a standalone J2EE application. The supported environments can be found in the document ‘EMC Documentum Content Management Interoperability Services Version 6.7 Release Notes’.
The deployment of CMIS for Documentum is very easy. You only have to deploy the CMIS application (emc-cmis.war for Servlet containers or emc-cmis.ear for several J2EE containers) with a modified dfc.properties file which contains the correct docbroker and bof-registry settings.
With Documentum 6.7 the CMIS application is installed on the methodserver by default. This provides an easy way to test CMIS, but it is not recommended to use this installation on a productive system.

2 Architecture of CMIS for Documentum

The application is based on Documentum Foundation Classes to communicate with the Content Server in the backend and on JAX-WS/Jersey to provide the API for clients. The CMIS functionality is directly mapped to DFC operations. For example, the CMIS queries will be translated to DQL queries. Other functionality like creating a document will be mapped to the concrete methods of Documentum Foundation Classes.

Suppose, you want to connect your customer specific application to a CMIS Server, e.g. the Documentum CMIS application and want to read all documents from the repository for a logged-in user. The following steps show how the application flow would look like:

1. Connecting to a CMIS server from a client perspective can be done in several ways. There are some CMIS frameworks out now which encapsulate the API (later more). On lowest level the application has to open a HTTP connection to the CMIS Server and send a HTTP request with a payload (SOAP message or ATOM message, both described in XML). Following code snippet shows the ATOM message from the client to the server to request the results of the given CMIS Query “SELECT cmis:objectId FROM cmis:document”.

2. The Documentum CMIS Server handles the incoming request, either by using JAX-WS for SOAP or Jersey for REST. In both cases, XML message will be translated into Java Objects which will be used for translating the given CMIS query into a DQL query.

3. The DQL Query can now be executed against the Content Server repository in the user context. As you may know, Documentum expects valid credentials for the user for doing anything. But how does the CMIS application know the current user and repository? Yes, you have to send the information within the request to the CMIS-server.

4. After processing the DQL query the Content Server returns with the results which are read by the DFC integrated in the CMIS Server. There might be some caching for paging functionality in CMIS, but it is not transparent to the user because the source code is not available.

5. Now again, the translation of the Java Objects into the response format can be done. The Java Objects will be mapped to XML (SOAP or ATOM, specific for the used binding).

6. The generated message will be send over the wire via HTTP response to the CMIS Client. The CMIS Client will than process the message and for example, show the documents in the custom application.

3 Comparison of DFC and CMIS

The following table compares Documentum Foundation Classes (DFC) and Documentum CMIS interface

Criteria	DFC	CMIS
Communication	DFC communicates with the RPC protocol with the Content server. The session is hold on the client.	Message-based communication which means to transfer the complete context in each message. Example: To move a document via CMIS, you have to send the repository-ID, the document-ID, the source-folder-id and the target-folder-id with the request.
Authentication	You have to authenticate one time in a session with username and password for a specified repository.	Each request has to contain the username and password (because it is based on stateless protocol HTTP!). SOAP-Binding: Usage of WS-Security-Standard. REST-Binding: Usage of http basic authentication. Encryption needed by using SSL.
Performance	Through the underlying protocol only changed data is transferred only when its needed. The object state is ‘hold’ on client side. You can use DQL for mass updates or deletions.	Each action must open a http connection, request a resource, get back the resource and end the http connection (or keep alive the connection). Yes, some CMIS frameworks like Apache Chemistry provide an object cache, but that´s not what you wanted in all cases. The transfer of messages is quite expensive due to the XML format and transformation. Additionally, CMIS only allows operations on one object at the same time. You can only get the ACL of one object at one time. Designing a communication concept is the most important work at the beginning of developing with CMIS to get an acceptable performance. Additionally, the performance impacts various from one vendor to another. CMIS for Documentum is a separate application, so using it instead of DFC means an additional server between custom application and Content Server. This means, CMIS must always be slower than using DFC! Alfresco, for example, integrates CMIS into the repository server itself, so it is using the same Repository API as webscripts. So there is no additional impact besides the XML transformation. Using caches for type definitions etc. on client application side is recommended to avoid unnecessary requests.
Transactions	For most parts of DFC you can easily wrap transactions around several actions. You can create several documents and if one creation failed, you can easily rollback the transaction in the code with a few lines of code.	CMIS is based on a stateless protocol. Due to this reason, each action (e.g. creating a folder) has its own transaction, so that a transaction for multiple actions is not possible out of the box. Instead the developer has to ensure that the code is written in the way that the rollback works. For example, when creating 5 folders and one fails, you have to delete the other folders by calling 4 times deleteFolder to rollback…

Afterwards there are some questions with the answers listed, which might be interesting for new CMIS developers.

Question	Answer
How can I create a new document?	You can use the createDocument -method of the ObjectService.
How can I create renditions with CMIS?	CMIS does not allow to create or update renditions. You can request renditions via getRenditions-method of the ObjectService.
How can I copy a document?	You can use the createDocumentFromSource-method of ObjectService.
How can I move a document?	Operation moveObject in ObjectService.
How can I delete a folder?	Empty folders can be deleted with the deleteObject -method of the ObjectService. To delete folders with content, use deleteTree -method of the ObjectService.
How can I search for objects?	You can use the query-method of the Discoveryservice. The query itself is based on CMIS-SQL, a SQL subset. The syntax is very similar to DQL, the Documentum Query Language. There are additional operators to request repeating attributes or the fulltext of the repository.
How can I create a new object type?	CMIS does not allow to create new type definitions. If you want to create a new definition, please use the tools of the vendor (e.g. Composer of Documentum). There are ideas to provide this functionality in future versions.
How can I create a link for a document?	You can use the addObjectToFolder of the MultifilingService. To remove the link, you can use removeObjectFromFolder . Be careful, this is repository specific. The repository does not have to provide it.
What about permissions in CMIS?	Reading and apply ACLs are supported by CMIS, but this is very basic. EMC extends the model of CMIS (cmis:read, cmis:write, cmis:all) with the specific Documentum rights. Because the ACL consists of users, groups or roles with specific permissions, it is not possible to determine the own rights or rights of other users via CMIS. It is only possible to get the allowed actions for the current user on one object.
How can I see which functionality is supported by the CMIS server?	The getRepositoryInfo-method of the Repository Services can be used to determine information about the capabilities of the specific CMIS implementation for the underlying ECM product. For example, Alfresco does not support to query the versionSeriesId property. Additionally, the service can be used to get the type definitions with all property definitions like name, datatype and cardinality.
Are concepts like virtual documents, workflows etc. supported?	These concepts are beyond the scope of CMIS. If you need them, it is not the correct use case for using CMIS. Some concepts, e.g. subscriptions might be possible with the use of relationships. Maybe next versions of CMIS will contain new functionality like Records Management.

4 Summary

CMIS for Documentum allows you to access documents and folders in the Documentum repository. The installation and configuration of the CMIS Documentum web application is very easy. You can really produce quick results as a developer and the services and methods are in general well designed. Due to protocol constraints and the early version, the CMIS specification in general has some shortcomings:

1. It is not fully prepared yet to allow batch CRUD operations, e.g. create a folder hierachy because of performance and transactions reasons.
2. It does not allow to create, update or delete objects via CMIS SQL.

Nevertheless, CMIS is the first step in the right direction. It will help developers to access different repositories with the same API.

Please always check in your projects if CMIS is the correct abstraction layer for the customer requirements. If you need total flexibility and enhanced functionality like workflows, use DFC. If you want to integrate different repositories from different vendors, CMIS is a good option.

Content Management Interoperability Services, short CMIS, is the new buzzword in the ECM world and is also the name for a new ECM standard. CMIS offers a common view and access on ECM repositories in terms of document management. It provides the least common denominator between all vendors which have been involved in the CMIS standardization.

Figure 1: History of CMIS
(see http://www.slideshare.net/alfresco/cmis-spec-uncovered, slide 5)

CMIS 1.0 as a standard was published in May 2010 by OASIS. It was a long way from beginning in late 2007 (see Figure 1). fme AG was also active with two employees in creation of the specification.

The first two chapters of the specification deal with the domain model and available services. This reference is ideal for developers which want to use CMIS to connect applications to one or more CMIS server.

Additionally, the technical description of the SOAP- and REST- binding is described in chapter 3 and 4. This part is intended to be used by vendors which want to implement CMIS server implementations in products or library developers like the developers behind Apache Chemistry (http://chemistry.apache.org/).

The spec can be found here:
http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html

The CMIS spec in detail

Figure 2 shows the logicial architecture of CMIS. A consumer (client) wants to access (read, write, update etc.) a content repository. CMIS is the glue between the client and the repository. It defines the services and the domain model which can be used by the client. A vendor mapping connects the CMIS services and domain model with the specific implementation of the content repository. Each Content Repository offers at least one API to connect to the repository, so mostly the implementation of CMIS is based on one of these APIs.

Figure 2: Logical architecture of CMIS
(see http://www.slideshare.net/alfresco/apache-chemistrywebinar/, slide 3)

CMIS defines 4 different general object types (see figure 3):

• document (standalone and elementary information asset)
• folder (container for other folders and documents)
• relationship (directional relationship between other object types)
• policy (policies for other objects like documents and folders, e.g. retention policies)

Figure 3: object types overview
(see http://www.slideshare.net/alfresco/apache-chemistrywebinar/, slide 5)

Each object type is described (see Figure 4) by:

• a number of parameters like the type id, the parent type, the display name and some others
• properties, a set of attributes with unique names. Following data types can be used in cmis- String, Decimal, Integer, Boolean, DateTime, URI, ID, XML and HTML. Properties can have constraints.
• Each object has a unique object id (cmis:objectId) which will be assigned on creation and which cannot be changed over lifetime.
• There are common attributes like the object name (cmis:name) or the last modification date (cmis:lastModificationDate) which are built-in (see Figure 5 ).
• Each custom type can define additional attributes.
• Documents can have content plus renditions and can be versionable.
• Folders have a unique path to identify the folder.

Figure 4: object type definition
(see http://www.slideshare.net/alfresco/apache-chemistrywebinar/, slide 6)

Figure 5: CMIS properties
(see http://www.slideshare.net/alfresco/apache-chemistrywebinar/, slide 7)

Services provide the functionality of the repository. The specification contains all functionalities of the services in detail. The following figure and table should give you a short overview, what is possible with CMIS and to help CMIS beginners to get a start working with it.

Figure 6: CMIS Services overview
(see http://www.slideshare.net/alfresco/apache-chemistrywebinar/, slide 15)

service	method	Description
Repository Services	getRepositories	Get a list of repositories that can be accessed from this service endpoint. No authorisation needed.
	getRepositoryInfo	Get information about the specified repository like product name, product version, supported CMIS version and capabilities of the CMIS implementation
	getTypeChildren	Get the list of Object-Types defined for the Repository that are children of the specified type.
	getTypeDefinition	Get the definition of a specified type with all property definitions. Is helpful for reading results of a query to know which property has which datatype.
Navigation Services	getChildren	Get the child objects which are contained in the specified folder. Paging allowed.
	getDescendants	Similar to getChildren, but more powerful. It can return all objects from a folder and its subfolders. No paging allowed.
	getFolderTree	Specialices getDescendants method which returns the folders from a specified folder and its subfolders. No paging allowed.
	getCheckedoutDocs	Returns the checkedout docs in one repository the current user has access to.
	getObjectParents	Returns the parent folder(s) for documents.
	getFolderParent	Returns the parent folder for a folder.
Object Services	createDocument	Creates a document with the specified type in the specified location
	createDocument-FromSource	Create a new document by copying an existing document.
	createFolder	Creates a new folder with the specified type in the specified location.
	createRelationship	Creates a relationship of the specified type.
	createPolicy	Create a policy object of the specified type.
	getAllowableActions	List of allowable actions for an object, e.g. if the user is allowed to checkout the document or apply an acl to the document.
	getObject	Read the object from the repository and get back properties, relationships, policyIds, renditions, Acls and allowable actions.
	getProperties	Get the list of properties for one object. Can be filtered by the properties which should be returned.
	getObjectByPath	Get an object path by using the human readable path to it, e.g. /folder/subfolder/document.gif
	getContentStream	Get the stream for the specified document or the stream for a specified rendition.
	getRenditions	Get the renditions associated for a document. Method only returns the properties, content by using getContentStream-method
	updateProperties	Update the properties of the specified object.
	moveObject	Moves the specified document/folder from one folder to another.
	deleteObject	Deletes the specified object by id.
	deleteTree	Deletes the specified folder and all child objects.
	setContentStream	Sets the new content for a specified document.
	deleteContentStream	Delethes the content from a specified document.
Multifiling Services	addObjectToFolder	Add an existing document to a folder.
	removeObjectFromFolder	Removes the document from a folder or from all folders.
Discory Services	Query	Executes a query in the repository. Query language is based on a SQL-subset plus some new operators for ecm-specific functions (in_folder –operator to allow search in a specific folder). The CMIS SQL language is read-only! No create, update or delete is possible.
	getContentChanges	Returns a list of changes of objects.
Versioning Services	checkout	Checkout a document (create a private working copy)
	cancelCheckout	Reverts the checkout (removes the private working copy)
	checkIn	Checks in the private working copy
	getObjectOfLastVersion	Get the lastest document object in the version series.
	getPropertiesOfLastVersion	Get a subset of the latest Document Objects in the version series.
Relationship Services	getObjectRelationships	Get all relationships for a specified object.
Policy Services	getAppliedPolicies	Get the list of polices applied for an object.
	applyPolicy	Apply a policy to an object.
	removePolicy	remove a policy from an object.
ACL Services	getACL	Return the currently applied acl for a folder or document
	applyACL	Sets a new acl by adding and removing AccessControlEntry

Please be careful by using these services. It is important to mention is that not every CMIS implementation supports everything. Please be careful when developing for different CMIS repositories. Several examples should show some small, but important differences:

• CMIS for Alfresco has no support for querying the cmis:versionSeriesId-attribute in a CMIS Query. In Documentum, this attribute is the i_chronicle_id, an id which is the same for all versions of an object. The root cause why Alfresco does not support it is that it uses a complete different versioning approach than Documentum. After testing with Documentum at first, my solution does not work in Alfresco and I had to find another solution.
• CMIS for Documentum has a different approach to get an object by path. Documentum allows to create documents with the same name in one folder. If this make senses or not, it restricts the getObjectByPath-method because the method should return exactly one document. In this case this functionaliy is only working by extending the path element of the document with its id, e.g. /folder/subfolder/1234567890123456_document instead of /folder/subfolder/document
• CMIS for Documentum 6.7 and Alfresco 3.3 don´t support the method getContentChanges of the Discoveryservice while other systems like Nuxeo already support it.

Available CMIS implementations

Most big ecm vendors have integrated a CMIS implementation into the products. The following table lists some of the products which are supporting CMIS 1.0.

CMIS implementations of ECM vendors

Future/Wishlist

CMIS 1.1 is coming. The current working draft can be found here. At a first glance, it provides a new binding, the JSON binding for browsers, type mutability and secondary types (aspects). The following list describes changes of CMIS I would like to see in future versions due to several reasons – performance, transactions and completeness:

CMIS should operate on multiple objects:
- CMIS SQL should offer create, update and delete for multiple objects
- Change the service interfaces to pass-in multiple cmis:objectIds (e.g. checkout or getObject)

CMIS should handle transactions:
- Built-In transaction handling and manually close/rollback transactions from the client.

CMIS should support getting users and groups.
- Currently there is no way to get users or groups from the repository. In this case, applying an acl to an object is dubious because you don´t know the users or group names

CMIS should allow to pass in an objectpath to in_folder()- and in_tree()-operator , e.g. select cmis:objectId from cmis:document where in_folder(/cabinet/folder).
Currently it is only supported to pass in an cmis:objectId.

CMIS should allow query a supertype of cmis:document AND cmis:folder via CMIS QL in one query.
Example: Select * from cmis:object where in_folder(‘id’)
It should return folders and documents.

CMIS should return the contentstream for checkout operation or create a new operation edit which allows to checkout and get back the contentstream of a document.

If you want to know, how is CMIS implemented for EMC Documentum, stay tuned and wait for the next blog article “CMIS for Documentum”.

Das bedeutet, dass vom Alfresco-System während des Checkout-Vorgangs nach der Sperre des Dokuments nicht sichergestellt ist, wo und ob sich dieses überhaupt im lokalen Benutzersystem befindet. Das führt zu eventuellen Zeitaufwänden beim Wiederauffinden des gewünschten Dokuments. Außerdem zwingt die Funktionalität die Benutzer indirekt zur Erstellung und Pflege ihrer jeweils eigenen internen Ordnerstruktur, um die Arbeitskopien übersichtlich und geordnet zu verwalten.

Des weiteren erfordert der Checkin-Vorgang einen erneuten Eingriff des Benutzers durch die Auswahl des Dokumentenpfades zum Upload von seinem lokalen System. Dieses Vorgehensmodell ist zwar unabhängig vom Betriebssystem des Clients und dem Dateitypen des zu bearbeitenden Dokuments, dennoch aus Sicht der Arbeitsergonomie optimierungsfähig. Alfresco bietet von sich aus einige Möglichkeiten an, wie beispielsweise den Zugriff über WebDAV oder das Microsoft Sharepoint-Protokoll, um den manuellen Eingriff zu automatisieren. Jedoch haben diese Lösungswege ihre Nachteile wie etwa die Einschränkung der Offline-Fähigkeit (WebDAV) und die mangelnde Unterstützung von nicht-Office Dokumenten (Sharepoint).

Der von der fme entwickelte Mechanismus zur Automatisierung des Content-Transfers basiert auf der Nutzung eines Java-Applets, welches Java ab der Version 1.5 unterstützt. Das Java-Applet übernimmt die Aufgaben für die Erstellung und Administration der Arbeitskopien sowie deren Zuordnung zu den Hauptdokumenten im Alfresco-System beim Uploadvorgang. Das Java-Applet ist plattformunabhängig und bedient Dokumente aller gängigen Formate, die auch vom jeweiligen Betriebssystem unterstützt werden.

Während das Java-Applet den Content-Transfer beim Checkout-Prozess im Hintergrund ablaufen lässt und somit keine Benutzeraktivitäten erfordert, bietet es für die Checkin-Operation ein leichtgewichtiges Userinterface für einen möglichen manuellen Eingriff, falls eine Arbeitskopie aus einem anderen lokalen Ablageort als den automatisch gepflegten verwendet werden soll. Dieses Checkin-Applet wird als eigenständige Alfresco-Komponente in den existierenden „Neue Version hochladen”-Dialog integriert.

Ablauf der Versionierung beim Einsatz des Checkin- /Checkout-Applets:

1.  Benutzer führt die Aktion „Offline bearbeiten” an einem Dokument aus

2.  Alfresco sperrt das Dokument

3.  Applet wird aufgerufen:

a. Ein Ordner mit einem Zeitstempel unter einem festdefinierten Pfad im Benutzersystem wird erstellt, um Speicherung zwei gleichnamiger Dateien zu verhindern

b. Eine lokale Arbeitskopie des Dokumentes wird in dem Ordner abgelegt

c. Die lokale Arbeitskopie wird im entsprechenden Programm zum Editieren geöffnet

d. Der Pfad der lokalen Arbeitskopie wird an Alfresco zurückgegeben und dort in den Eigenschaften der Arbeitskopie gespeichert.
 

   

Abbildung 2: Checkout-Vorgang: Erstellung der lokalen Ablagestruktur für die zu bearbeitende Arbeitskopie

Checkin:

1.  Benutzer führt die Aktion „Neue Version hochladen” in Oberfläche von Alfresco Share an dem ausgecheckten Dokument aus

2.  Alfresco-Upload-Formular wird geöffnet

3.  Applet wird aufgerufen:

a.  Der Pfad der Arbeitskopie wird ausgewertet

b.  Besteht die Datei, wird sie bereits in dem Upload-Formular vorselektiert. Besteht sie nicht, kann ein neues Dokument manuell über den Kopf „Durchsuchen” ausgewählt werden

4. Benutzer klickt auf Dokument hochladen

5. Die lokale Arbeitskopie wird vom Applet in das Alfresco-System hochgeladen und anschließend automatisch vom lokalen Benutzersystem entfernt.

Abbildung 3: Checkin-Vorgang: „Neue Version hochladen”-Dialog mit der applet-gesteuerten Benutzeroberfläche

 Abbildung 4: Checkin-Vorgang: Auswahl einer Arbeitskopie aus einem anderen lokalen Ablageort

Das Applet bietet weiterhin Potenzial zum Einsatz für weitere Anwendungsbereiche und Funktionalitätserweiterungen. Insbesondere Download- und View-Funktionen könnten ebenfalls vom Applet bedient werden, um beispielsweise doppelte Downloads zu vermeiden. Außerdem wird Alfresco-Share aktuell um eine zusätzliche Funktion „Weiterbearbeiten” erweitert, um den Editierungsvorgang an der Arbeitskopie auch zum späteren Zeitpunkt fortsetzen zu können.

Nahezu jedes Unternehmen kommuniziert in der heutigen Zeit über das Medium E-Mail. Alle denkbaren Dokumentarten werden auf dem elektronischen Postweg sowohl unternehmensintern als auch zwischen Geschäftspartnern ausgetauscht. Diese Praxis bietet enorme wirtschaftliche Vorteile, allerdings birgt sie auch Risiken, denn die gesetzlichen Vorschriften, u.a. aus dem Handels- und Steuerrecht oder dem Datenschutzrecht gelten selbstverständlich auch für das E-Mail-Format. Zum Beispiel wurde im Jahr 2004 ein Manager einer Großbank zu 18 Monaten Haft verurteilt, weil er per E-Mail Mitarbeiter dazu aufgefordert hatte, aufbewahrungspflichtige Unterlagen zu vernichten. Unternehmen werden nach dem Gesetz verpflichtet, Inhalte von E-Mails entsprechend der jeweils gültigen Aufbewahrungsfristen einerseits aufzubewahren und andererseits, beispielsweise im Zuge einer Steuerprüfung, unverzüglich vorlegen zu können. Darüber hinaus sind Unternehmen gut beraten, rechtsrelevante Inhalte von E-Mails aus Eigeninteresse aufzubewahren, um im Fall eines Rechtsstreits eine lückenlose Dokumentation der Geschäftsprozesse vorlegen zu können. Die genannten Anforderungen stellen viele Unternehmen vor eine enorme Hürde, da die wenigsten mit dem Einzug des Mediums E-Mail die technischen und organisatorischen Maßnahmen zur Erfüllung der Anforderungen in die Geschäftsprozesse eingeführt haben.

Der Einsatz von EMC SourceOne hilft Unternehmen dabei, die Anforderungen an das E-Mail Management zu erfüllen. Ein Großkunde der fme AG legt beispielweise den Anforderungsschwerpunkt im Thema E-Mail Management auf das stringente Löschen von E-Mails nach Ablauf einer definierten Aufbewahrungsfrist, um auf eDiscovery Fälle vorbereitet zu sein. Die Konzeption und Umsetzung für nahezu 100.000 Postfächer verlangt eine stringente Projektplanung und ein durchdachtes Rolloutkonzept sowie eine exakte Konfiguration von EMC SourceOne.

Architektur von EMC SourceOne

EMC SourceOne verfügt über mehrere Komponenten. Für den SourceOne Betrieb sind die Komponenten Datenbank (SQL Server), Master Server und Worker Server Grundvoraussetzung. Der Master Server erzeugt Jobs und stellt diese für die Worker Server zum Abholen und Abarbeiten zur Verfügung. Die Worker Server prüfen regelmäßig, ob Jobs für die dem Worker Server zugewiesenen Rolle zum Abarbeiten bereitstehen. Einem Worker Server können eine oder mehrere der folgenden Rollen zugewiesen werden: Archive, Index, Search, Retrieval. Zusätzlich können optional die Komponenten Web Services, Mobile Services und viele weitere zum Einsatz kommen. Diese sind Grundlage für die Nutzung zusätzlicher Funktionen wie zum Beispiel der webbasierten Suche und der Auflösung von “Shortcuts” (siehe Folgekapitel).

Ein großer Vorteil von EMC SourceOne ist die Skalierbarkeit der SourceOne Systemlandschaft. Dabei handelt es sich um eine “n+1″-Technologie. Dies bedeutet, dass die Erweiterung einer bestehenden Systemumgebung jederzeit problemlos möglich ist, selbst im laufenden Produktivsystem. Je nach Unternehmensgröße und vorhandenem Datenvolumen kann die Anzahl der benötigten physikalischen Server mit Hilfe von EMC SourceOne Tools jederzeit kalkuliert werden. Durch die “n+1″-Technologie können zudem Serverausfälle sehr gut kompensiert werden. Fällt zum Beispiel ein Worker Server mit der Rolle Indexierung aus, übernimmt der nächste verfügbare Worker Server, welcher die Index Rolle zugewiesen hat, diese Aufgabe.

Funktionsweise von EMC SourceOne

EMC SourceOne unterstützt im Standard Microsoft Exchange und Lotus Domino Umgebungen. Eine der Kernfunktionen von EMC SourceOne ist die Entlastung der Mailserver im Unternehmen, wobei die vorhandenen E-Mails zum Beispiel vom MS Exchange Server in das so genannte SourceOne Native Archive portiert werden. Innerhalb des SourceOne Native Archives besteht die Möglichkeit der Konfiguration und Aktivierung von Aufbewahrungsfristen und der automatischen Vernichtung der E-Mails nach Ablauf der Aufbewahrungsfristen. E-Mails und deren Anhänge werden innerhalb des SourceOne Archivs “de-dupliziert”, d.h. dass Mails und Attachments mit identischer Aufbewahrungsfrist nur jeweils einmal vorgehalten werden und somit auch nur einmal den Archivspeicher belegen.
EMC SourceOne bietet zudem die Option des so genannten “Shortcutting”. Hierbei werden die in Postfächern vorhandenen E-Mails zunächst wie oben beschrieben in das SourceOne Native Archive portiert. Im Anschluss werden die E-Mails in den Benutzerpostfächern durch einen Link ersetzt, so dass das Datenvolumen auf dem Mailserver stark reduziert wird. Greift ein Benutzer auf eine “Shortcut” E-Mail zu, wird er automatisch zum SourceOne Archiv weitergeleitet. Von hier aus kann die E-Mail direkt aufgerufen werden. Noch komfortabler ist der direkte Zugriff über den EMC SourceOne Offline Access Client, welcher die im Postfach existierenden “Shortcuts” direkt beim Zugriff durch den Benutzer auflöst, so dass dieser bis auf die Darstellung der E-Mails in Outlook keine Änderungen in der Arbeitsweise spürt.

Generell ist der Einsatz von EMC SourceOne für verschiedene Szenarien denkbar. Die Lösung kann zum Beispiel lediglich serverseitig konfiguriert und eingesetzt werden, so dass die Auswirkungen für den Endbenutzer sehr gering sind. Der Endbenutzer muss in diesem Fall nicht selbst tätig werden. Die Archivierung der E-Mails im SourceOne Native Archive geschieht vollautomatisch nach zuvor definierten Regeln. Eine Regel könnte zum Beispiel wie folgt heißen: alle E-Mails in den Postfachordnern “Posteingang” (inklusive aller Unterordner) und “Gesendete Objekte” (inklusive aller Unterordner) sollen archiviert werden, sofern die E-Mails älter als 30 Tage sind und eine Größe von jeweils 1 MB inklusive aller Anhänge nicht überschreiten. EMC SourceOne kann jedoch auch so konfiguriert werden, dass der Endbenutzer proaktiv E-Mails in vordefinierte Ordner z. B. in MS Outlook archiviert. Hierbei handelt es sich um das so genannte “User directed archiving”, kurz “UDA”. Durch vorher zu definierende Regeln werden Ordner systemseitig für einen abgeschlossenen Nutzerkreis in Microsoft Outlook zur Verfügung gestellt. Mitglieder dieses Nutzerkreises werden dadurch in die Lage versetzt, E-Mails innerhalb von Outlook in die bereitgestellten Ordner zu verschieben. Vorteil ist, dass der Endbenutzer am Archivierungsprozess aktiv beteiligt wird und somit sichergestellt werden kann, dass nur ausgewählte, aufbewahrungswürdige E-Mails im EMC SourceOne Archiv aufbewahrt werden.

Durch den Einsatz von EMC SourceOne ist eine Kombination der beschriebenen Lösungen (serverseitige und benutzergesteuerte Archivierung) möglich.

Administration von EMC SourceOne

Die Administration von EMC SourceOne geschieht über die SourceOne Management Console. Diese stellt die Zentrale der SourceOne Systemlandschaft dar. Über die SourceOne Management Console können alle Aktivitäten gesteuert, alle durchgeführten Jobs eingesehen und die Berechtigungsstruktur verwaltet werden. Die Verwaltung der E-Mails einzelner Benutzer und Gruppen kann durch den Einsatz der webbasierten SourceOne Search dezentral gestaltet werden. Je nach eingesetzter Berechtigungsstruktur kann Benutzern die Möglichkeit gegeben werden, über die SourceOne Search beispielsweise alle E-Mails, bei welchen sie direkte (“Von:”; “An:”) oder indirekte (“CC:”; “BCC:”) Kontaktperson sind, zu finden, einzusehen, diese wiederherzustellen (z. B. in das eigene Postfach) und aus dem SourceOne Archiv zu löschen. Der Aufwand und die Ressourcen für eine zentrale Administration und Durchführung solcher Tätigkeiten kann demnach minimiert werden.

Hier der Nutzen von SourceOne in der Übersicht:

• Spürbare Entlastung von MS Exchange / Lotus Domino
• Anforderungen an eine E-Mail Management Lösung werden erfüllt durch

o   Einhaltung von Aufbewahrungsfristen

o   Automatische Vernichtung nach Ablauf von Aufbewahrungsfristen

o   Zentrales E-Mail Archiv; Inhalte können unverzüglich bereitgestellt werden

• Serverseitige oder benutzergesteuerte E-Mail Archivierung oder Kombination aus beiden Lösungen
• Maximale Skalierbarkeit, Optimierung der SourceOne Systemlandschaft
• Deutliche Einsparung im Storagebereich durch “De-Duplizierung”
• Sehr wenig Änderungen für den Endbenutzer (Human Change Management)
• Administrationsaufwand kann gering gehalten werden durch Nutzung der webbasierten SourceOne Search; Endbenutzer können E-Mails direkt im Postfach wiederherstellen
• Einfache Konfiguration der Regeln und Aktivitäten innerhalb EMC SourceOne

Fazit
Je nach Anforderung des Unternehmens an den E-Mail Management Prozess können die verschiedenen Funktionen von EMC SourceOne deutlich zur Erhöhung der Compliance-Sicherheit beitragen. Die Kernfunktionen und Stärken von EMC SourceOne liegen in der Archivierung und automatischen Vernichtung von E-Mails nach bestimmten Kriterien sowie einem damit verbundenen Berechtigungsmodell für Zugriffe auf archivierte E-Mails.