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.

Gesetze und Regularien verpflichten, Dokumente (Dokumentationen) nach bestimmten Vorgaben aufzubewahren. Geschäftsführer und Vorstände haften bei Verstößen persönlich und gesamtschuldnerisch. Hinzu kommt das Eigeninteresse des Unternehmens, bestimmte Geschäftsdokumente und Unternehmenswissen organisiert abzulegen und auch gezielt unter Einhaltung von gesetzlichen Vorgaben. Rechtskonformes Dokumentationsmanagement bezeichnet die effektive Steuerung zur sicheren Aufbewahrung und die kontrollierte Vernichtung von Dokumenten und Dokumentationen über den gesamten Lebenszyklus. Die Technologie ermöglicht auf diese Weise von der Collaboration-Phase über die Dokumentenmanagement-Phase, die Records Management-Phase bis in die Archiv-Phase den kontrollierten Umgang mit Unternehmensinformationen. Nicht mehr notwendige Dokumente können so kontrolliert vernichtet werden.

Wichtige Ziele des rechtskonformen Dokumentationsmanagements sind die Einhaltung von Gesetzen, Verordnungen und anderer Regularien in allen Geschäftsbereichen. Dies gilt auch und insbesondere für die technische Dokumentation von Produkten. Werden in ihnen doch die für die Klärung von Haftungsfragen in einem Schadenfall wichtigen Informationen zur Sicherheit und zum bestimmungsgemäßen Gebrauch gegeben. Nebenbei führt eine verbesserte Wiederauffindbarkeit durch ein Dokumenten-Management-System (DMS) zu einer erhöhten Wiederverwendung von qualitätsgesicherten Dokumenten und Textpassagen. Dies reduziert Fehler und schafft gleichzeitig Ratioeffekte bei der Herstellung der Dokumentation.

Unter Beachtung der Faktoren Mensch, Prozess, Technologie und Methode lassen sich die genannten Ziele mit Umsetzung eines rechstkonformen Dokumentationsmanagment-Systems erreichen.

Mit der richtigen Methode wird sichergestellt, dass die Lösung (Faktor Technik) die Anforderungen aus Sicht der Anwender (Faktor Mensch) und aus Sicht effizienter Arbeitsabläufe (Faktor Prozess) erfüllt und die Rechtskonformität erzielt wird.

Abbildung: Schritte zum rechtssicheren Dokumentationsmanagement

Die Methode

Dabei wird zunächst über ein Assessment der Handlungsbedarf festgestellt. In einer Records-Management-Richtlinie werden die konkreten Ziele, Inhalte und Verantwortungen für das Unternehmen individuell formuliert.

Dokumentenarten und die dazugehörigen Aufbewahrungsfristen und ihre Ablagestrukturen werden definiert und die Regelwerke dokumentiert.

Die Definition neuer Anwenderrollen, wie z.B. die für die Verwaltung des Systems zuständige Rolle des „Retention Manager” zählt zum Faktor Mensch. Hier muss beachtet werden, dass die Anwender u.U. neue Arbeitsweisen umsetzen müssen. Umso wichtiger ist daher eine anwenderfreundliche, fehlerarme Benutzbarkeit des Systems. Diese Anforderungen spiegeln sich im Faktor Technik als Design der Benutzeroberfläche wieder. Aus Sicht des Faktors Prozess werden neue Abläufe für die Deklaration von Records, für die Verwaltung von „Legal Holds” im Falle von Gerichtsverfahren und Löschprozesse eingeführt. Dabei werden Dokumente entweder manuell durch den Anwender oder automatisiert klassifiziert und innerhalb des Systems mit Metadaten versehen und abgelegt. Anhand der Klassifizierung werden systemseitig die vorab definierten Aufbewahrungsregeln angewendet. Von diesem Zeitpunkt an garantiert das System die Unveränderlichkeit der Dokumente. Über die Protokollierung aller relevanten Aktionen im System wird die Nachvollziehbarkeit sichergestellt. Sind alle Aufbewahrungskriterien erfüllt, erfolgt eine kontrollierte Vernichtung der Dokumente, wahlweise komplett automatisiert oder nach einem definierten Freigabe-Prozess.

Die technische Konzeption und Implementierung eines rechtskonformen Dokumentationssystems inklusiver Benutzerakzeptanztests ist der nächste Schritt. Dabei sollte auf eine integrierte Verwaltung des Lebenszyklus sowie auf die Aufbewahrungsfristen unter Sicherstellung der Unveränderlichkeit geachtet werden. Bei bereits vorhandenen DMS-Implementierungen kann die Rechtssicherheit durch die Erweiterung um Records-Management-Funktionen gesteigert werden.

Die Einführung der Lösung sollte durch Maßnahmen des Change Managements wie z.B. Projektmarketing und zielgruppengerechte Trainings flankiert werden, um die Mitarbeiter frühzeitig einzubeziehen. Der Faktor Mensch wird hier leider zu häufig vernachlässigt.

Insgesamt erreichen Sie durch die Einführung von Records Management Komponenten in Zusammenhang mit einem Dokumenten-Management-System eine höhere Transparenz und Nachvollziehbarkeit von Änderungen an Dokumenten. Doppelarbeit durch das Überschreiben von Information entfällt. Betriebsgeheimnisse werden besser geschützt und Daten sind sicher vor Verlust und Manipulation. Die Beschäftigung mit den eigenen Prozessen hilft bei ihrer Optimierung. Automatisches Löschen senkt Speicher- und Administrationskosten und die Einhaltung von Aufbewahrungsfristen vermindert insbesondere juristische Risiken.

xPlore besteht aus zwei Komponenten: dem Index Agent und dem Index Service. Der Index Agent exportiert Daten und Dokumente nachdem diese geändert wurden und stellt sie dem Index Service zum Indizieren zur Verfügung. Der Index Service baut auf Lucene und EMC´s xDB auf. Lucene ist ein OpenSource Softwareprojekt von Apache und basiert auf einem Java Suchmaschinen-Framework, mit dem Text-Indizes erzeugt und durchsucht werden können.

EMC hat nach internen Tests folgende Ergebnisse bekannt gegeben:

• 50% höheren Durchsatz bei Suchanfragen
• 40% höherer Datendurchsatz beim Indizieren von Dokumenten
• 9x Performancesteigerung bei „underpriviliged users“
• Kosteneffiziente vertikale und horizontale Skalierbarkeit
• Hohe Verfügbarkeit – xPlore unterstützt N+1 aktiv/passiv Instanzen im Cluster und aktiv/aktiv Instanzen mit shared data
• Disaster recovery – xPlore unterstützt online Backup (hot backup)
• Datenspeicher – xPlore unterstützt sowohl SAN als auch NAS

• Virtualisierung – eine Installation auf eine VM wird unterstützt

xPlore – Die wesentlichen Unterschiede zu FAST

Änderungen bei xPlore:

• alle Suchbegriffe werden mit “Und” und nicht wie bei FAST mit “Oder” verknüpft
• Gruppen und ACL´s werden mit indiziert
• es gibt keine Wildcards mehr
• Wegfall einer Beschränkung der Ordnertiefe
• Eigenständige Administrationsoberfläche

Die Teilworterkennung der Volltextsuche kann aktiviert werden, nach Aussagen von EMC wirkt sich dieses aber negativ auf die Performance aus und das mit dem Faktor 3. Durch die Indizierung der Berechtigungen mittels ACL und Gruppen werden die Suchergebnisse bereits auf dem Indexserver gefiltert und nicht erst auf dem Content Server. Dies führt zu einer deutlichen Verbesserung der Performance. Somit wird zum Beispiel nicht für jedes Dokument eine Zusammenfassung generiert. Jedoch bleibt bei diesem Verfahren ein kurzer Zeitrahmen, in dem Dokumente mit den veralteten Rechten indiziert sind. Dies kann dazu führen, das Nutzer Dokumente über die Suche finden auf denen Ihnen kurz zuvor die Berechtigung entzogen wurde.

xPlore – Administration

Documentum liefert für xPlore eine eigene Administrationskonsole aus. Dieser wird auf dem JBoss des Index Servers installiert und bietet eine Vielzahl an Möglichkeiten für die Überwachung und Administration.

  Abbildung 1: xPlore Administrator

Mit dem Auditing des Index Servers können eine Vielzahl von Auswertungen gefahren werden. Zum Beispiel können die langsamsten/schnellsten Querys selektiert werden oder welcher User welche oder wie viele Suchanfragen gestellt hat.

Auch der Index Agent bringt ein Administrationsinterface mit, über das der Index Agent gestartet und gestoppt werden kann. Zusätzlich besteht die Möglichkeit über eine DQL-Query Dokumente oder Typen nachträglich zu indizieren.  Weiterhin bietet der Index Agent einen “reindex” Modus, mit dem sich einfach den Index neu aufgebaut werden kann.

Mögliche Konfigurationen / Strategien

Mehrere Instanzen des Index Service können von einem oder mehreren Index Agents bedient werden. Somit wird die Last des Indizierens auf die Instanzen verteilt. Die Instanzen können auf verschiedener Hardware installiert werden und benötigen lediglich Zugriff auf die gemeinsam genutzten Daten.  

Abbildung 2: xPlore Aufbau (xPlore-Deploymelt Guide)

Weiterhin besteht die Möglichkeit, mehrere Index Agents so zu konfigurieren, dass sie sich die zu indizierenden Daten teilen. Ein Index Agent verarbeitet die zu indizierenden Dokumente und der andere übernimmt nur die Indizierung der Typen „dm_acl“ und „dm_group“. Auf diese Weise ist sichergestellt, das auch beim Import einer großen Menge von Daten die Berechtigungen aktuell bleiben.

FAST durch xPlore ablösen

Für die Ablösung von FAST in einer Produktivumgebung durch xPlore bietet EMC ein Szenario zur „sanften“ Migration. Hierbei indiziert xPlore das Repository, während FAST normal weiter arbeitet und die Suchanfragen beantwortet. Sobald xPlore das komplette Repository indiziert hat, kann der aktive Wechsel von FAST zu xPlore vorgenommen werden. Mit diesem Dual Mode ist sichergestellt, dass die Suche auch während der Migration erreichbar bleibt.

Der Office Metadata Service bietet eine Synchronisation, bei der als Benutzeroberfläche wahlweise Masken in EMC² Documentum oder Microsoft Office verwendet werden können.

Der Office Metadata Service kann unter anderem auch als ein wertvoller Baustein eingesetzt werden, falls Dokumenten-basierte Arbeitsprozesse auf EMC² Documentum abgebildet werden sollen. Der Office Metadata Service wird bereits bei Kunden der Fertigungsindustrie in den Bereichen Reklamationsmanagement, Auftragsabwicklung und Qualitätssicherung eingesetzt.

Systemablauf bei Attributierung in Documentum:

1.)    Attribute werden in EMC² Documentum angegeben

2.)    Documentum Content Server ruft Office Metadata Service auf

3.)    Office Metadata Service synchronisiert die Attribute und speichert das Dokument in EMC² Documentum ab

  Systemablauf bei Attributierung in Microsoft Office:

1.)    Attribute werden in MS Office angegeben (wahlweise in Attributen, Feldern oder Excel Tabellen)

2.)    Das Dokument wird in EMC² Documentum eingecheckt

3.)    Documentum Content Server ruft Office Metadata Service auf

4.)    Office Metadata Service synchronisiert die Attribute und speichert die Attribute in EMC² Documentum

Beispiel in Microsoft Office:

Dokumentennummer wird in Microsoft Properties angegeben

Beispiel in EMC² Documentum:

Dokumentennummer wird in Attributmaske angegeben

Synchronisation der Attribute:

In dem früheren Blog Artikel bin ich schon mal auf die Motivation zur SAP SharePoint Integration eingegangen. Obwohl viele ähnliche Anwendungsfälle denkbar sind, besteht bei dieser Art immer die Forderung, SAP Datensätze mit den zugehörigen Dokumenten aus dem Archiv nach SharePoint zu transferieren und dort einen externen (SharePoint-) Workflow zu starten. Wie man eine solche Lösung umsetzen könnte will ich in diesem Blog beschreiben.

Das Vorgehen zeichnet sich dadurch aus, dass die Kommunikation SOA basiert stattfindet. Die Kommunikation erfolgt ausschließlich zwischen einem Web Services Provider und einem Web Service Consumer. Die gesamte Logik, die beschreibt wie die Informationen in SharePoint gespeichert werden, wird innerhalb des ASP.NET Web Services beschrieben.

Übertragung der Daten zwischen SAP und SharePoint

Im ersten Schritt muss auf dem IIS, auf dem die SharePoint Webapplikation gehosted wird, ein Web Service Provider eingerichtet werden (Visual Studio 2010). In dem Web Service wird eine so genannte WSDL (Web Service Definition Language) Datei generiert, die den Web Service beschreibt. Die WSDL Datei (XML Datei) besteht im Wesentlichen aus einer Beschreibung, in welcher Form die Daten erwartet werden (Attributname und Datentyp) und der externen http-Adresse, unter der der Dienst erreichbar ist. Nachdem der Web Service Provider inklusive der WSDL Datei erstellt wurde, kann im ABAP-Editor der Web Service Proxy erstellt werden. Dazu wird beim Erstellen des Proxy die WSDL Datei angegeben mit der der WS Proxy erzeugt wird. Damit stehen auf beiden Seiten entsprechende Methoden zur Verfügung, die zur Datenübertragung verwendet werden können. In einer Methode innerhalb des SAP Workflows wird der Web Service Proxy verwendet, um die Daten an den Web Service Provider zu schicken. Die eigentliche Kommunikation erfolgt damit auf Basis des SOAP Protokolls, in der sowohl die Datensätze als auch die Dokumente (binär) enthalten sind.

Bereitstellung der Daten in SAP

Der externe Prüfungsworkflow muss durch den SAP Anwender initiiert werden. Es muss also ein entsprechender Button in der SAP Maske zur Verfügung gestellt werden, mit dem der SAP Workflow aufrufbar ist. Die Bereitstellung wird innerhalb einer Methode definiert, die von einer Aufgabe innerhalb des SAP Workflows aufgerufen wird. Da innerhalb von SAP häufig Views-Strukturen verwendet werden, müssen die Tabellen, in denen die Buchungssätze hinterlegt sind, individuell zusammengestellt werden. Die benötigten Dokumente werden anhand der Archive Link Tabelle ermittelt. Innerhalb der ABAP Methode müssen zuerst die benötigten Daten aus dem Buchungssatz abgefragt werden, um sie in der SOAP Nachricht in XML Form zu verpacken. Dies geschieht mit Standard SAP Funktionsbausteinen. Zur Abfrage der benötigten Dokumente vom Content Server existieren ebenfalls vorgefertigte Funktionen die lediglich die Archive Link ID des Dokuments benötigen. Da die Buchungssätze bereits abgefragt wurden, ist die ID bekannt.

Speicherung der Daten in SharePoint

Der Methode des Web Service Providers wird der Inhalt der SOAP Nachricht übergeben und kann damit verwendet werden. Bei der Speicherung der Daten sind natürlich zahlreiche Möglichkeiten vorhanden. In diesem Beispiel nehme ich eine einfache Liste in der die einzelnen Informationen aus dem SAP Datensatz gespeichert werden und die Dokumente als Attachement angehängt werden. Die dafür benötigte Liste muss bereits vorhanden sein. Beim Arbeiten mit den Listenelementen kann die SharePoint Server API verwendet werden. D.h. beim Aufbau der SharePoint Strukturen kann das SharePoint Object Model verwendet werden. Die Weiterverarbeitung bzw. das Freigeben/Ablehnen kann dann als einfacher Workflow implementiert werden.

fme kooperiert in diesem Umfeld mit CYA und hat mit dem US-amerikanischen Softwareunternehmen eine Technologie- und Reseller-Partnerschaft geschlossen. CYA Technologies bietet mit dem Produkt SmartRecovery™ seit Jahren die führende Backup- und Recovery-Lösung für Documentum und Filenet auf dem US-Markt. Als Reseller Partner bietet fme sowohl die Software als auch die Dienstleistung zur Einführung in die Systemlandschaft nun auf dem europäischen Markt an. Das Angebot umfasst die Installation und Konfiguration der Software, die Ausbildung der Administratoren und auch die Beratung für eine konsistente und umfassende Backup- und Recovery-Planung und Implementierung in die Systemlandschaft.

Als einzige Lösung bietet CYA SmartRecovery™ sogenannte „Hot“-Backups im laufenden Betrieb der Server, synchronisierte Backups sowie die Möglichkeit zur Laufzeit des Systems selbst, die Inhalte einzelner Objekte (Dokumente) mitsamt ihrer Metadaten wiederherzustellen.

Die Software sichert die Datenintegrität, hilft enge Service Level Agreements einzuhalten und vermeidet logische Datenfehler durch die Möglichkeit einzelne, mehrere oder tausende von Dokumenten und Dateien schnell und komplett in Ihrem Documentum Repository konsistent wiederherzustellen. Der Status des Dokuments im Lifecycle, Workflow etc. und alle Beziehungen zu anderen Objekten werden wieder hergestellt ohne die Documentum Server herunterzufahren.

• Hohe manuelle Erfassungs- und Verarbeitungskosten
• Hohe Fehleranfälligkeit
• Lange Durchlaufzeiten
• Dokumentenverlust
• …

Aus diesen Gründen wurde in den letzten Jahren viel Geld investiert, um die Rechnungsverarbeitung durch elektronische Prozesse in SAP abzubilden. Besonders häufig treffen wir auf die folgenden drei Varianten:

• Archivierung ohne OCR und Workflow
  (Spätes Ablegen mit Barcode)
• Archivierung ohne OCR aber mit Workflow
  (Ablegen für spätere Erfassung)
• Verarbeitung mit OCR und mit Workflow

Wie man erkennen kann, sind diese Implementierungen aus dem Bedarf nach einer Veränderung entstanden. Unternehmen haben damit begonnen den Rechnungsverarbeitungsprozess Schritt für Schritt elektronisch abzubilden und abhängig von der Durchdringung trifft man auf diese verschiedenen Evolutionsstufen. Bei der Rechnungsverarbeitung mit OCR und Workflowunterstützung ergeben sich zahlreiche Vorteile zur Steigerung der Prozessqualität, -geschwindigkeit und -flexibilität. Mit Hilfe des SAP Business Workflow werden alle Aktivitäten von der Validierung der OCR Daten über die Vorerfassung bis zur Buchung und Zahlung gesteuert. Folglich werden alle Arbeitsschritte in SAP durchgeführt und obwohl eine Vielzahl der Prozessbeteiligten nur selten Zugriff auf SAP benötigen, fallen für diese Anwender Lizenzkosten an. Am häufigsten ist dies bei der Rechnungsfreigabe der Fall. Aus diesem Grund bieten einige Hersteller von Rechnungseingangslösungen sogenannte SAP Webflow Zusatzlösungen an.

Kann das nicht auch SharePoint? Das haben wir doch ohnehin im Haus.

Die SharePoint Technologien (2010 und auch 2007) eignen sich hervorragend, um diese Aufgabe zu übernehmen. Die Verlagerung des Rechnungsfreigabeprozesses für einen bestimmten Personenkreis von SAP nach SharePoint zielt zwar eindeutig auf die Einsparung von Lizenzkosten ab, jedoch hat die Praxis gezeigt, dass sich dadurch auch weitere Vorteile wie höhere Prozessqualität, höhere Prozessdurchlaufgeschwindigkeiten (Skonto) und Beseitigung von Produktivitätshürden (Vertreterregelungen) ergeben. Zudem werden Synergien genutzt indem SharePoint als Lösungsplattform für weitere Services im Unternehmen verwendet wird.