Das SAP-Team der fme wächst weiter! Seit Juni diesen Jahres leitet Georg-Stefan Lösch das Team und startet gleich durch mit neuen SAP-Kunden-Projekten. Seit 1999 ist er als SAP Consultant für SAP Business Workflow & Geschäftsprozessoptimierung im Geschäft und bringt spezielle SAP-Kenntnisse im Bereich Digitaler Rechnungseingang, Vertrags- und Immobilienmanagement, SAP Modulen  (FI,CO,MM, SD, HR) mit und ist bestens vertraut mit Dokumentenmanagement (SAP ArchiveLink, SAP Records Management, LiveLink DocuLink) in diesem Umfeld.

Hauptaugenmerk der laufenden und angehenden SAP-Projekte des Teams liegt auf der optimalen Ausschöpfung der vorhandenen ECM-Potentiale unter Nutzung des existierenden SAP-Systems.

Ziel dabei ist es, die notwendigen Informationen direkt aus den führenden betriebswirtschaftlichen Anwendungskomponenten heraus zur Verfügung zu stellen – und zwar genau dann, wenn diese für Unternehmensentscheidungen oder die täglichen operativen Aufgaben in einem Unternehmen benötigt werden. Darin sind sich Experten einig: das Zusammenführen von SAP mit Enterprise Content Management im Rahmen der Geschäftsprozesse bietet ungeahnte Potentiale.

Wertvolles Unternehmenswissen „schlummert“ oft in Dateisystemen oder in Papierakten. ECM eröffnet den Unternehmen die Möglichkeit, betriebliche Abläufe zu verbinden und zu beschleunigen, kürzere Time to Market von Dienstleistungen und Produkten zu erzielen, die Sicherheit der Informationen zu gewährleisten, Kosten für Informationslogistik zu senken und Gesetze, Verordnungen und Richtlinien einzuhalten.

Basierend auf der mehr als 10-jährigen ECM-Erfahrung zeigt die fme ihren Kunden auf, wie unter Nutzung des im Unternehmen existierenden SAP-Systems vorhandene ECM-Potentiale kostenoptimiert und anwenderfreundlich ausgeschöpft werden können.

 ECM-Komponenten innerhalb der SAP Architektur

Unsere Kunden profitieren bei der Realisierung dieser Nutzenpotentiale von dem SAP ECM Know-how des fme/SAP-Experten-Teams, ergänzt durch unser breites Partnernetzwerk und professionelle Add-On Lösungen, insbesondere in den Themenfeldern:

• Input Management

Eine einheitliche und intelligente Eingangsverarbeitung von elektronischen und Papierdokumenten ermöglicht eine schnelle Weiterverarbeitung im SAP.

• SAP Business Workflow

Die Abbildung von (dokumentenintensiven) Geschäftsprozessen im Rahmen der Eingangsverarbeitung sowie aus dem Aktenmanagement heraus stellt eine wesentliche Komponente des SAP-ECM dar.

• Archivierung

Eine SAP-Archivierungslösung für die Ablage von Dokumenten schafft Rechtssicherheit. Zusätzlich kann durch die Archivierung alter Daten die SAP-Datenbank entlastet werden. Der Zugriff auf archivierte Dokumente geschieht transparent innerhalb des SAP-Systems über die generischen Objektdienste und den zugehörigen Business-Objekten.

• SAP Records Management

Eine Aktenverwaltungsplattform auf SAP-Basis ermöglicht die direkte Integration wichtiger Geschäftsdaten gekoppelt mit einem effizienten Dokumentenmanagement. Wichtige Geschäftsprozesse können zudem im Rahmen der Aktenverwaltung kontrolliert und durchgeführt werden.

ECM-Themen im SAP-Umfeld

Wir unterstützen unsere Kunden dabei, dokumentenbezogene SAP-Prozesse zu automatisieren und fortlaufend zu optimieren. Wir helfen bei der Lösungsfindung für die individuellen Anforderungen und in der zielgerichteten Abbildung der konkreten Aktenstrukturen – von der Anforderungsanalyse bis zur Implementierung und darüber hinaus! Dabei werden die vorhandenen Geschäftsprozesse zielgerichtet analysiert und diese anschließend auf Basis von SAP Business Workflow oder SAP Records Management effizient umgesetzt. Dabei verwenden wir u.a. auch Lösungen unserer Partner tangro und xft.

Ebenso helfen wir bei der Wahl eines geeigneten Archivsystems und unterstützen mit juristischer Kompetenz dabei, Compliance-Richtlinien zu erarbeiten und Verfahrensdokumentationen, die vom Gesetzgeber in diesem Zusammenhang gefordert werden, zu erstellen.

Im Rahmen des Workshops „PLM Zukunftstrends“ im Schweizer Rapperswil, eine Veranstaltung der IG-PLM aus der Swiss PLM Workshop-Reihe, wurden zukünftige PLM-Themen aus Sicht des Mittelstands diskutiert.

Anbei kurz die Ergebnisse des Workshops:

Themen des Mittelstands mit dem meisten „Demand“ am Markt sind:

• Globale Entwicklungsumgebung (Zusammenarbeit)
• Mechatronic
• Informationsbedarf aus allen Systemen (Inseln)

Globale Entwicklungsumgebung (Zusammenarbeit)

• der Mittelstand lagert zunehmend Entwicklungsaufgaben an ausländische Standorte aus
• große Herausforderung ist die Schaffung eines weltweit genutzten PDM-Systems, weniger das standortübergreifende Concurrent Engineering
• Replikationsszenarien werden den Anforderungen nicht gerecht

- insbesondere bei komplexen CAD-Daten

- und dem Schutz des Know hows, insbesondere bei der Zusammenarbeit mit Fernost

Mechatronic

• Viel ungelöste Themen wie z.B.

- das Zusammenspiel von Mechanik und Elektrik/Electronic (Software) wird nicht unterstützt

- „neue Sichten“ z.B. Funktionssicht

• Die allermeisten PDM/PLM-Anbieter haben in diesem Umfeld kaum Antworten
• ECAD und MCAD Systemanbieter haben bisher wenig Interesse, entsprechende Lösungen zu schaffen

Informationsbedarf aus allen Systemen (Inseln)

• Produktrelevante Daten werden immer noch von einer Vielzahl von Systemen verwaltet (siehe auch PLM- Lösungen)
• Einfache Suchmöglichkeit mit Zusammenhängen über alle Systeme wäre für die meisten Anwender schon ein riesiger Fortschritt
• Technologisch sind Lösungsansätze vielversprechend, die Lizenzthematik hinsichtlich Zugriff auf die jeweiligen Systeme wurde bisher kaum beachtet

Digitale Fabrik ist an sich nur bei großen Unternehmen (Automobilindustrie) ein Thema

PLM Lösungen
Alle Versuche und Projekte, um unternehmensweite PLM-Datenmodelle zu erstellen, sind gescheitert (monolithischer Ansatz). Auf der anderen Seite ist kein Anbieter in der Lage, alle PLM relevanten Daten und Prozesse sauber zu unterstützen. Der Trend geht deshalb dazu über in etwa gleichstarke Plattformen für PDM, ERP, DMS und CRM aufzubauen. Die Systeme unterstützen die entsprechenden PLM-Phasen trotz Schnittstellenthematik besser, als es ein durchgängiges System eines Anbieters kann. SAP kommt dem ideal noch am nächsten. In der Realität werden SAP PDM und SAP ERP trotzdem meist getrennt betrieben.

Demzufolge sind flexible Integrationen (siehe Informationsbedarfe) gefragt.

PLM Anbieter
Die CADnahen PLM Anbieter versuchen Ihre Kunden durch das unlösbare “Verheiraten” von CAD und PDM zu binden. Dies widerspricht völlig den Anforderungen der Kunden, insbesondere der Zulieferindustrie.
PDM/PLM-Lizenzen bleiben teuer. Es ist nicht erkennbar, dass die Lizenzkosten für Informationsnutzer wesentlich sinken

PDM/PLM Projekte
Die meisten Projekte haben ihren ROI noch nicht erreicht oder werden ihn nie erreichen. Insbesondere die durch PLM-Anbieter gesteuerten Projekte tun sich hier besonders hervor.
Nicht angesprochen Themen, welche jedoch zunehmend relevant werden:

Cloud Computing

• Application Service Providing (ASP)
• Software as a Service (SaaS)

Unternehmen 2.0

• Soziale Netzwerke
• Wiki / Blog
• …

Business Intelligence

• Engineering Cockpit
• …

Open Source Lösungen

Collaboration (Zusammenarbeit) nicht nur aus der Sicht der verteilten Entwicklung (strukturierte Zusammenarbeit) erforderlich, auch phasen- und abteilungsübergreifend, insbesondere in den frühen unstruktierierten Innovationsphasen.

Fazit
Mit den Themen “Sharepoint (Collaboration) meets PLM” und unserer Vision PDM, DMS und ERP zu verbinden, adressiert die fme AG topaktuelle Themen. Dies bestätigt sich in Gesprächen mit unseren Kunden und dem Start entsprechender Projekte.

Using Apache JMeter and RRDtool as a Performance Suite for EMC² Documentum Applications

Introduction

Application performance monitoring is an essential part in today’s system environment of every large company. The user community is expecting that application performance degradation is notified by the system responsibles long time before they realise it. Another often heard desire is to simulate and forecast system response times from remote sites spread all over the world. Now it is not at all a trivial task to set up a system which can fulfil such requirements. In the following a potential answer for these questions based on two open source tools is outlined.

Apache JMeter

Apache JMeter is an OpenSource software, a 100% pure Java desktop application designed to load test functional behaviour and measure performance (http://jakarta.apache.org/jmeter) in an easy way. The picture below shows the configuration window (left part)  and a possible result presentation window (right part).

JMeter can be used to simulate load on a server, network or object to test its strength or to analyze overall performance under different load types in different circumstances. The tests work for static and dynamic resources. The results can be presented in graphical or tabular form and easily adjusted to do any kind of graphical output required.

A strong feature of this tool is the ability to build test scenarios in distributed environments (e.g. test web applications from different remote locations) with the help of Remote Method Invocation (RMI).

RRDtool

RRDtool is an OpenSource application to perform high performance data logging and graphing system for time series data (http://oss.oetiker.ch/rrdtool/). Own custom monitoring shell scripts or whole applications can be build using its Perl, Python, Ruby, TCL or PHP interface to extend the application.

EMC² Documentum Measurements with JMeter

Due to the high configuration flexibility of JMeter it is possible to create different test scenarios for Documentum. Even highly customized Documentum applications can be tested.  Different test scenarios can be:

• Login, Logout
• Search
• Check-In, Check-Out
• Import, Export of objects with different sizes
• Navigation within folder hierarchies
• Attribut opening
• and many more …

For Key Performance Indicators (KPI’s) based on the above mentioned scenarios it is possible to set up jobs collecting data over long time periods (days, weeks, months or even years). The data can be presented as time series on an online monitoring web page or similar.

Application Example

In this examples different scenarios from above within Webtop were measured and plotted. All of these individual times are added up to a total time which is shown in yellow. To the total time a data fit was applied to indicate the tendency of system behaviour over time. “Holes” within the plot are resulting from non available data (measurement was stopped in this case).

Data Representation with RRD

The next plot shows the timing of a standard search over several days (measurement frequency 5 minutes)

The last plot was created for the checkin/checkout times created with a JUnit test incorporated into JMeter. As for the plots before the time period for the measurement were several days and the time interval was set to 5 minutes.

In none of the shown examples a significant degradation of performance could be detected.

Adding Documentum Applications into System Monitoring

With the above mentioned methods it is also possible to add the application monitoring to an existing system monitoring by sending information with the Simple Network Management Protocol (SNMP) .

Summary

Apache JMeter and RRD are two open source tools allowing extensive system performance measurements and building performance forcast scenarios for remote sites  in a flexible and fast manner.

The possibilities are not limited to the examples shown above.  Any web based application or Junit Test can be measured and presented in such a way.

]]> http://ecm-blog.fme.de/allgemein/2010-05/apache-jmeter-and-rrdtool/feed http://ecm-blog.fme.de/allgemein/2010-05/sap-documentum-integration http://ecm-blog.fme.de/allgemein/2010-05/sap-documentum-integration#comments Fri, 21 May 2010 08:39:27 +0000 Jochem Cornely http://ecm-blog.fme.de/?p=900 Über die Möglichkeiten des Zugriffs von SAP- und NonSAP-Benutzern auf archivierte Dokumente und deren nachträgliche Verknüpfung von Documentum mit SAP.

Zum Standardszenario eines etablierten Dokumentenmanagementsystems wie Documentum gehört die Möglichkeit, in SAP zu archivieren. Von SAP wurde hierfür schon frühzeitig eine Schnittstelle geschaffen - SAP ArchiveLink. Wie sieht es aber mit erweiterten Ablage- und Zugriffsmöglichkeiten von bzw. auf Dokumente -verlinkt zwischen SAP und Documentum- aus? Welche Komponenten von Documentum müssen eingesetzt werden und was leisten diese, wenn folgende Anforderungen bestehen:

1.) SAP-Content aus SAP in Documentum ablegen

2.) Zugriff von SAP- und Non-SAP-Usern auf Content in Documentum verlinkt mit SAP-Objekten

3.) Verlinkung von bestehendem Content aus Documentum nach SAP

Zur Beantwortung dieser Fragen ist ein genauer Blick auf die benötigten Module und Komponenten von Documentum notwendig. Wir nehmen dabei Bezug auf die o. a. Anforderungen.

A. Archive Services for SAP (AS4SAP)

Dieses Modul ist eine Grundkomponente und muß immer verwendet werden, wenn in Zusammenhang mit SAP archiviert wird. AS4SAP wird dabei von allen anderen Documentum-Modulen genutzt. Mit den AS4SAP können aus SAP heraus Dokumente über SAP ArchiveLink archiviert werden. Neben der Dokumentenarchivierung wird AS4SAP auch zur Datenarchivierung benötigt.

Neben der Archivierung ist AS4SAP auch für den Zugriff aus SAP auf archivierte Dokumente erforderlich. Da AS4SAP auf ArchiveLink aufsetzt, ist in SAP keine zusätzliche Installation notwendig d.h. es gibt keine Transporte, die eingespielt werden müssen. In SAP muss aber abhängig vom eingesetzten Archivierungsszenario entsprechendes ArchiveLink-Customizing durchgeführt werden.

Erfüllung der Anforderungen:

Anforderung 1.): komplett abgedeckt

Anforderung 2.): nur der Zugriff von SAP-Usern auf Dokumente, NICHT von Non-SAP-Usern

B. Content Services for SAP (CS4SAP)

Die CS4SAP bestehen aus mehreren Teilmodulen. Sie lassen sich einteilen in die Server Components und die Client Components.

Abbildung 1: Ab Version 6.5 sind die „Content Services für SAP“ in die Documentum Administration integriert

B.1 Server Components

High Processing Volume Server (HVPS)

Der HVPS automatisiert die Zuordnung zwischen SAP-Objekten und Dokumenten in einem Documentum-Repository. Er sorgt auch für die Synchronisation der Metadaten zwischen SAP und Documentum. Der HVPS nutzt das SAP PLM-Modul. SAP PLM besteht aus einem Satz API-Funktionen, mit denen das SAP-System von externen Applikationen angesprochen werden kann. Um eine Verbindung von SAP-Objekten zu Dokumenten in Documentum herzustellen, werden sogenannte Document Info Records (DIR) in SAP angelegt. Der DIR enthält individuell definierbare Dokumentattribute wie z.B. die Beschreibung, die DocID, die Dokument-Version, ein Datum und eine Referenz auf ein spezifisches Dokument im Documentum-Repository. Der HVPS wird auf einem Java-Application-Server installiert. Wie schon bei den AS4SAP ist in SAP keine Installation, sondern nur Customizing erforderlich, da der Zugriff über das SAP PLM und durch SAP-Queries erfolgt.

Agent

Zu den Server Components gehört auch die “Agent”-Komponente. Sie besteht aus drei Teilen: “Actions”, “Agents” und “Jobs”.

Es gibt fünf Arten von “Actions”:

• Verknüpfung von SAP-Objekten an Documentum-Objekte
• Verknüpfung von Documentum-Objekten an SAP-Objekte
• Integrationsprüfung der Links zwischen SAP und Documentum
• Replikation von SAP-Objekten nach Documentum
• Replikation von Documentum-Objekten nach SAP

Die Actions beruhen auf Queries (Documentum-Queries und SAP-Queries), die bestimmte Objekte identifizieren und den zugehörigen Task beschreiben. Mit den Queries werden Daten aus dem einen System ermittelt, die auf Datenstrukturen des jeweils anderen Systems gemappt werden können. Die Actions werden von “Agents” ausgeführt. In dem Agent wird festgelegt, welches SAP-System genutzt wird und welcher User es ausführt. Die Jobs sind Ausführungspläne, die festlegen, wann welcher Agent läuft.

Erfüllung der Anforderungen:

Anforderung 2.): B1 (Server Components) schafft die Vorraussetzung, für den Zugriff von Non-SAP-Usern”. Der eigentliche Zugriff erfolgt dann über die B.2 (Client Components).

Abbildung 2: Komponenten der Content Services for SAP

B.2 Client Components

Folgende Client-seitige Komponenten gibt es und sind für den jeweiligen Bedarf einzusetzen:

View

“View” muß auf jedem PC installiert werden, von dem aus auf Dokumente zugegriffen werden soll. “View” erlaubt den Zugriff sowohl auf SAP (erfordert SAP User-Account) als auch auf Documentum (mit Documentum User-Account).

Erfüllung der Anforderungen:

Anforderung 2.): erfüllt für SAP-User und Non-SAP-User

Webview

Mit “Webview” kann per Browser auf Documentum zugegriffen  werden, um sich dort Inhalte anzeigen zu lassen, die aus SAP gelinkt oder repliziert wurden. Webview ist auf WDK aufgebaut (ähnlich wie Webtop), bietet aber weniger Möglichkeiten zur Bearbeitung des Dokuments.

Erfüllung der Anforderungen:

Anforderung 2.): erfüllt für Non-SAP-User

Capture

Die Capture-Komponente wird genutzt, um Dokumente aus Scanning-Applikationen in Documentum abzulegen und SAP zuzuordnen. Dies wird z.B. von „EMC Captiva InputAccel“ genutzt.

Manage

Mit der Manage-Komponente können Benutzer Verknüpfungen zwischen Documentum und SAP-Objekten erzeugen, aktualisieren und löschen.

Erfüllung der Anforderungen:

Anforderung 3.): erfüllt

Webadmin

Die Webadmin-Komponente ist eine Erweiterung des Documentum-Administrators. Er erlaubt die Konfiguration des Systems (u.a. Definition von Queries, Actions, Agents und Jobs).

Webtop

Standard-Client für Documentum. Wenn die Metadaten zu den Dokumenten aus SAP repliziert wurden, lassen sich die Dokumente über den Webtop mit der Standardsuche finden.

Erfüllung der Anforderungen:

Anforderung 2.): erfüllt für Non-SAP-User

C. Weitere Komponenten

Content Services for SAP Portal

Zur Anzeige von Inhalten eines Documentum Repositories innerhalb des SAP-Portals

Documentum Process Services for SAP

Zur Verknüpfung von SAP Business Workflows und Documentum-Workflows

Fazit

Abschließend lässt sich festhalten, dass alle drei Anforderungen mit entsprechenden Modulen und Komponenten von Documentum erfüllt werden können. Dokumente lassen sich nicht nur nachträglich mit SAP-Objekten verknüpfen, sie können auch außerhalb von SAP mit zusätzlichen Attributen aus SAP-Tabellen recherchiert und angezeigt werden. Für die Erfüllung  der beschriebenen Anforderungen ist neben der Installation der Komponenten allerdings stets auch eine kundenspezifische Implementierung in SAP und Documentum vorzunehmen.

• Wie überhaupt funktioniert DFS?
• Was muss ich im Vergleich zur Documentum Foundation Classes, kurz DFC, beachten?

Die technische Basis von DFS sind Web Services, ein Begriff für mehrere Technologien, die in diesem Umfeld zum Tragen kommen. Durch den elementaren Unterschied des Kommunikationsprotokolls von Remote Procedure Calls (RPC) bei DFC und dem nachrichtenbasierten Kommunikationsprotokoll bei DFS ist ein Paradigmenwechsel beim Datenaustausch eingetreten. DFS verlangt es, sich mehr Gedanken darüber zu machen, wann welche Daten vom Repository abgerufen und zum Repository verschickt werden, um eine performante Anwendung zu entwickeln. Voraussetzung für diesen Artikel sind Kenntnisse in Web Services. Mehr Informationen zu Web Services sind hier zu finden.

Konfiguration und Installation der Documentum Foundation Services

Die DFS-Anwendung ist eine J2EE-Webapplikation auf Basis von Servlets und kann auf den von EMC unterstützten J2EE-Server installiert werden. Die Zahl der unterstützten Server in den Release Notes ist groß- der JBOSS Application Server 4 wird jedoch von EMC empfohlen und wird auch bereits in einem Installationspaket mitgeliefert.

Da DFS über die DFC kommuniziert (dazu später mehr), müssen in dem Auslieferungspaket Konfigurationsänderungen vorgenommen werden. In der EAR (Enterprise Application Archive)-Datei befindet sich die Konfigurationsdatei dfc.properties, in der alle notwendigen Einstellungen (Docbroker, Global Registry, DFC Einstellungen) vorgenommen werden müssen. Dafür ist es notwendig, das EAR-File zu entpacken, die Änderungen vorzunehmen und dann wieder zu packen. Danach einfach die EAR-Datei auf dem Server deployen, Server starten und fertig. DFS ist jetzt schon bereit, genutzt zu werden. Welche Funktionen genutzt werden können, erfahren Sie im ersten Blogartikel zum Thema DFS.

Kommunikation und Verarbeitung mit den Documentum Foundation Services

DFS als Serverkomponente muss ständig bereit sein, Anfragen einer Clientkomponente entgegen zu nehmen und zu verarbeiten. DFS baut daher auf dem Java-Standard-Webserviceframework JAX-WS (https://jax-ws.dev.java.net/) auf, um die Kommunikation mit Webserviceclients zu ermöglichen und die Umwandlung der ankommenden SOAP-Nachricht nach Java und umgekehrt zu bewerkstelligen.

Innerhalb der DFS-Anwendung ist die eigentliche Logik der einzelnen Dienste wie z.B. dem Queryservice und dem Objectservice implementiert. Diese Logik mappt die Funktionen der Operationen der einzelnen DFS-Dienste auf die Funktionen der DFC. Welche DFC-Funktionen in welcher Art und Weise genutzt werden, bleibt dem Nutzer verborgen. Der Quellcode von DFS liegt nicht offen, d.h. man erkennt nicht, wie die Funktionen umgesetzt sind. Lediglich die Logfiles geben ein wenig Aufschluss darüber, was im Hintergrund passiert.

DFS kann bei einigen wenigen Operationen Caches nutzen, um z.B. die Ergebnisse einer Suchanfrage für eine bestimmte Zeit vorzuhalten und eine erneute Suchausführung zu vermeiden. Dies ermöglicht z.B. ein schnelles Paging der Suchergebnisse.

Die Kommunikation und Verarbeitung mit dem DFS-Webservice soll anhand eines Beispiels in Abbildung 1verdeutlicht werden.

Abbildung 1: Kommunikationsablauf bei DFS

1. Eine Java-Applikation möchte z.B. für einen angemeldeten Nutzer die vorhandenen Cabinets in einem Repository per DQL abrufen. Codelisting 1 zeigt, wie von der Java-Applikation aus mit dem Queryservice der DFS kommuniziert werden kann. Es wird dabei ein SOAP-Client im Speicher erzeugt, um über HTTP(S) eine SOAP-Nachricht an den DFS-Service zu versenden und auch die Ergebnisse zu verarbeiten. Die daraus generierte SOAP-Nachricht, die über HTTP(s) an DFS versendet wird, ist in Codelisting 2 dargestellt.
2. Die SOAP-Nachricht ist nun über ein Servlet der DFS-Anwendung im Applicationserver angekommen und wird durch das Framework JAX-WS in Javaobjekte umgewandelt. Die Anfrageparameter stehen nun in Form von Javaobjekten zur Verarbeitung zur Verfügung.
3. Nun greift die entsprechende Logik, die per DFC-API die Suche gegen das angegebene Repository ausführt. Dabei wird die Suche unter dem Nutzer ausgeführt, der beim Abruf des Service übergeben wird.
4. Die Ergebnisse der Suche werden vom Content Server an die DFS-Applikation zurückgegeben und können nun in das entsprechende Java DFS-Datenmodell verpackt werden.
5. Ob die Suchergebnisse im Cache abgelegt werden, lässt sich beim Abruf von der Javaapplikation aus steuern.
6. Die Ergebnisse in Form von Javaobjekten werden nun wiederum in XML, genauer gesagt in das SOAP-Schema, umgewandelt und an die Javaapplikation über HTTP zurückgesendet. Die Java-Applikation kann nun die Ergebnisse verarbeiten und z.B. diese dem Nutzer an der Oberfläche darstellen.

Codelisting 1: Java-Client zum Abruf der Cabinets mit Hilfe des Queryservice von DFS (Beispiel aus der DFS Dokumentation entnommen und modifiziert)

Codelisting 2: Beispiel für eine SOAP-Nachricht der Operation execute im Queryservice via HTTP (Beispiel aus der DFS Dokumentation entnommen und modifiziert)

Unterschiede zwischen Documentum Foundation Services (DFS) und Documentum Foundation Classes (DFC)

Das oben dargestellte Beispiel lässt die Vermutung aufkommen, dass DFS im Prinzip genauso benutzt werden kann wie die DFC, denn schließlich verwendet DFS die DFC im Hintergrund ebenso (wie wir gerade gelernt haben).

Dass dies nicht so ist, wurde schon am Anfang des Artikels deutlich: DFS ist und kann im Standard bei weitem nicht so performant wie die DFC sein. Schließlich ist DFS eine weitere Kommunikationsschicht zwischen dem Content Server, der DFC-Kommunikation und der eigenen Anwendung. Vor allem die Umwandlung der SOAP-Nachrichten, die sehr groß werden können (z.B. Abruf von 37.000 OrdnerobjektIds und deren Ordnerpfade ergibt z.B. eine 1,2 Mb große SOAP-Nachricht) und deren Übertragung kostet Zeit. Jeder Aufruf zum Contentserver bringt einen gewissen Overhead mit, der bei der DFC allein jedoch nicht ganz so stark ins Gewicht fällt.

Die Performance ist sicherlich sehr wichtig, jedoch unterscheiden sich DFS und DFC in anderen Punkten ebenso. Aus diesem Grund werden DFS und DFC in der Tabelle 1 anhand einiger Kriterien zusammenfassend gegenübergestellt.

Tabelle 1: Gegenüberstellung DFC und DFS

Fazit

Dieser Artikel gibt einen Überblick zur Installation und zur Funktionsweise der Documentum Foundation Services, insbesondere zum Kommunikationsablauf. Deutlich wird, dass zwar einerseits die Komplexität in der Nutzung für Documentum-Einsteiger verringert wird, die DFS-API an sich ist leicht verständlich. Andererseits muss bei der Entwicklung mit DFS von Anfang einige Punkte, vor allem die Performance, beachtet werden. Wie man das Performance-Problem in den Griff bekommen kann und welche Dinge es noch zu beachten gibt, erfahren Sie im letzten Blogartikel zum Thema DFS.

Was sind Web Services?

„A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”
(W3C Web Services Architecture Working Group, August 2003)

Ein Web Service lässt sich nach dieser Definition nicht auf eine Technologie beschränken, sondern bündelt Basiskomponenten wie SOAP, Web Service Description Language und XML. Web Services kapseln Funktionen, die von einfachen Datendiensten wie z.B. der Abfrage und Rückgabe von Kundendaten bis hin zu komplexen Geschäftsprozessen reichen. Dabei können Dienste entwickelt werden, um neue Funktionen abzubilden bzw. um eine Schnittstelle zu alten Anwendungen zu bieten.

Der Zweck von Web Services ist es, standardisierte Nachrichten zwischen einem Sender, meist einem Client, und einem Empfänger, meist einem Server, auszutauschen. Die Kommunikation kann in beide Richtungen verlaufen (Request-Response-Mechanismus) und unterstützt damit vorrangig eine Client-Server-Architektur wie in Abbildung 1 dargestellt. Im Web Service-Umfeld spricht man daher auch von einem Servicenutzer, dem Client, der Daten anfragt, und einem Serviceanbieter, dem Server, der Daten liefert bzw. verarbeitet.

Abbildung 1: Client-Server-Architektur 

Die folgenden Kerntechnologien werden bei Web Services benutzt:

• eXtensible Markup Language (XML)
• Web Service Description Language (WSDL)
• SOAP

Auf XML soll an dieser Stelle nicht weiter eingegangen werden. Mehr Informationen sind unter http://www.w3.org/XML/ zu finden.

Die Web Service Description Language

Die WSDL ist die XML-basierte Beschreibungssprache für Web Services. Damit können funktionale Aspekte eines Services standardisiert abgebildet werden. Da XML ohne ein entsprechendes XML-Schema frei aufgebaut sein kann, wurde ein XML-Schema definiert, das besagt, wie eine Schnittstellendefinition eines Web Service formal auszusehen hat. Die aktuelle Version von WSDL ist 2.0 und die Spezifikation dazu ist unter http://www.w3.org/TR/wsdl20/ zu finden.

Die WSDL beschreibt vereinfacht gesagt folgendes:

• Welche Dienste bieten
• welche Operationen (inkl. Parameter)
• unter welcher Adresse an?

Abstrakt kann man sagen, dass WSDL für XML das ist, was Interfaces für Java sind. Die Schnittstelle an sich ist jedoch programmiersprachenunabhängig und bildet damit den Dreh- und Angelpunkt zwischen einem Serviceanbieter und Servicenutzer. Damit kann z.B. der Web Service in Java programmiert sein und der Web Service Client in C#.

Abbildung 2 zeigt den schematischen Aufbau einer WSDL-Datei. Erkennbar ist, dass das WSDL-Format einen stark hierarchischen Aufbau hat. Die Elemente haben Abhängigkeiten untereinander und bauen aufeinander auf. Dadurch steigt die Wiederverwendung, indem einzelne Teile der WSDL ausgelagert werden können. Die einzelnen Bestandteile der WSDL werden in Tabelle 1 näher beschrieben.

Abbildung 2: Aufbau der WSDL 

Tabelle 1: Erklärung der WSDL-Bestandteile 

Auf die Darstellung eines Beispiels soll an dieser Stelle verzichtet werden. Daher erfolgt hier nur ein Verweis auf ein Beispiel unter der URL http://www.w3.org/2001/03/14-annotated-WSDL-examples.html.

SOAP

Wenn ein Dienstnutzer eine in WSDL definierte Schnittstelle nutzen möchte, wird eine Dienstkommunikation benötigt, die zwischen Serviceanbieter und Servicenutzer stattfindet. Diese Dienstkommunikation kann technisch auf verschiedene Arten umgesetzt werden. Neben den Spezifikationen XML-RPC und Distributed Data Exchange (WDDX) wird in der Praxis vor allem SOAP favorisiert. Es stellt zurzeit das wichtigste Kommunikationsprotokoll für Web Service-Anwendungen dar und basiert auf XML.

In Abbildung 2 wird der Kommunikationsablauf mittels SOAP über das Transportprotokoll HTTP veranschaulicht. Es zeigt den grundsätzlichen Ablauf einer Kommunikation zwischen Serviceanbieter und Servicenutzer. Analog kann der Ablauf auf andere Transportprotokolle übertragen werden, denn SOAP ist grundsätzlich nicht an HTTP gebunden, wird aber am häufigsten damit benutzt.

Abbildung 3: synchroner Kommunikationsablauf mittels SOAP via HTTP-Protokoll 

Der Kommunikationsablauf kann in folgende Schritte unterteilt werden:

1. Innerhalb einer Anwendung wird mittels SOAP-Client eine SOAP-Nachricht mit den Nutzdaten erzeugt.
2. Die Übertragung findet unter Nutzung von etablierten Standards statt. In diesem Fall ist das HTTP. Der SOAP-Client erzeugt einen HTTP-Client, der die Übertragung der SOAP-Nachricht zum Server übernimmt.
3. Auf dem HTTP-Server wird die Nachricht empfangen. Der SOAP-Server leitet die Nachricht zum Web Service weiter. Dieser kann die übertragenden Informationen extrahieren und verarbeiten.
4. Falls die Bearbeitung im Web Service erfolgt ist, wird die Nachricht zurück zur Anwendung gesendet. Im Fall von HTTP wird die Nachricht über die noch vorhandene, offene Verbindung (HTTP-Session) gesendet. Dadurch trifft die Nachricht wieder bei der Anwendung ein.

Wie jedoch sehen diese Nachrichten aus, die ausgetauscht werden? Genau dies legt SOAP fest, denn es definiert das Format und den Aufbau der Nachrichten, die Dienstanbieter und Dienstnutzer per Datenübertragung austauschen. Die Struktur wird in Abbildung 3 dargestellt. Deutlich wird daran, dass grundsätzlich ein Umschlag (SOAP-Envelope) den optionalen Kopf (SOAP-Header) und den obligatorischen Körper (SOAP-Body) kapselt. Der Header kann wiederum mehrere Informationen in Form von XML-Elementen enthalten. Er bietet meist Platz für Angaben zur Sicherheit und Routing. Der Body enthält im Gegensatz dazu die zu übertragenden Nutzdaten, d.h. ein XML-Fragment passend zur Schnittstellenbeschreibung (Stichwort WSDL!). Dieser Aufbau ist in Abbildung 4 zu sehen.

Abbildung 4: Aufbau von SOAP-Nachrichten 

Beispiele für SOAP-Nachrichten sind ebenfalls unter der URL http://www.w3.org/2001/03/14-annotated-WSDL-examples.html zu finden.

Fazit

Der Artikel vermittelt grundsätzliches Wissen zum Thema Web Services und erklärt die wichtigsten Fakten zu den Technologien WSDL als Schnittstellenbeschreibungssprache und SOAP als Nachrichtenformat. Die Documentum Foundation Services selbst sind mehrere Dienste vereint unter einer SOAP-Schnittstelle und sind durch mehrere WSDL-Dateien in ihrer Funktion beschrieben. Wie die Nutzung dann im Detail funktioniert, erfahren Sie im nächsten Artikel zum Thema DFS.

Dieser Artikel setzt die Reihe der Screeencasts zur Einführung in den Composer fort und befasst sich mit Problemen, die beim Einsatz des Composers entstehen können. (Der erste Artikel beinhaltet Informationen zur Installation und Verwendung des Composers.)

Für Einsteiger ist es oft schwierig, die Ursache für Fehlermeldungen zu finden. Deshalb werden in diesem Screencast die wichtigsten Stellen erläutert, an denen mit der Fehlersuche begonnen werden kann.

In EMC-Produkten, eine unserer Softwareplattformen, steckte bisher wenig SOA. Zum Zugriff auf das Content Repository standen bisher die Documentum Foundation Classes, kurz DFC, und die Content Server API zur Verfügung. Dies sollte sich nach Meinung von EMC ändern, denn mit Documentum 6.0 wurde erstmals ein Produkt namens Documentum Foundation Services, kurz DFS, ausgeliefert. Mittlerweile ist mit dem Produkt Documentum Restful Services (zurzeit im Early Access Programm) eine REST-basierte Variante der DFS auf dem Weg gebracht. Informationen zu REST finden Sie im Blogartikel Resource Oriented Architecture - Das WWW fürs Unternehmen.

In Documentum 6.5 wurde DFS z.B. um einen Dienst zum Verwalten von Berechtigungssätzen und erweiterten Funktionen für virtuelle Dokumente erweitert und auch in Documentum 7 wird es wieder zusätzliche Funktionen geben. Diese Blogserie soll klären, ob sich der Einsatz von DFS nach derzeitigem Stand lohnt und ob es die Entwicklung von inhaltsbasierten Anwendungen erleichtert. Der erste Blogartikel wird einen Überblick zu DFS geben. Weitere Blogartikel gehen technisch tiefer ins Detail und diskutieren erste Erfahrungen mit DFS.

Motivation

„Wird die Documentum Foundation API (DFC) demnächst durch DFS abgelöst?” werden Sie sich jetzt vielleicht fragen. Schließlich ist die DFC eine mächtige API, die es schon lange gibt und bisher gute Dienste geleistet hat. Die Antwort ist klar und einfach: Nein, DFS wird die DFC nicht ablösen, denn schließlich ist DFS nur eine Hülle um die DFC. DFS baut auf der DFC auf und wird sie damit nicht ersetzen können!

„Warum sollte man dann eine Abstraktion um die DFC bauen?” Auf den ersten Blick gibt es durch die Einführung von DFS mehrere Vorteile. Durch das offene Protokoll SOAP und WSDL können alle Plattformen unterstützt werden, die mit XML umgehen können. Das sind eine Menge von Programmiersprachen wie z.B. C# bei .NET, in denen ein Zugriff auf das Repository möglich ist. Zudem sind offene Protokolle gern gesehen bei großen Unternehmen. Sie machen flexibel und erleichtern Änderungen an den Softwaresystemen. Ein Zugriff auch durch Firewalls steht damit oftmals nichts im Wege.
Andererseits möchte EMC nicht den Anschluss an die neuesten Technologie-Trends verlieren und beweist damit, dass ihr Produkt Documentum auch SOA-fähig ist.

Documentum Foundation Services- ein Überblick

DFS ist ein zusätzliches Produkt von EMC und wird ab Version 6.5 von Documentum standardmäßig kostenlos mit ausgeliefert. Es wird auch schon in anderen Clients von EMC wie z.B. Centerstage, MyDocumentum Offline + for Outlook eingesetzt. Da DFS in Form einer J2EE-Applikation entwickelt wurde, ist dafür ein Applikationsserver notwendig. Ist DFS installiert, lassen sich diverse Funktionen über eine definierte Webservice-Schnittstelle nutzen.

Für die Kommunikation notwendig sind Datenmodelle, um z.B. mit Dokumenten und Ordnern agieren zu können oder Access Control Lists anzulegen. Exemplarisch ist in Abbildung 1 das Datenmodell für einen Großteil der Funktionen für den Umgang mit Objekten dargestellt. Für den Workflowservice und den AccessControlListService gibt es separate Datenstrukturen. Diese sollen an dieser Stelle nicht weiter vertieft werden.

Folgende Elemente sind in der Grafik ersichtlich:

- ein Datenpaket (Datapackage) ist nichts weiter als ein Behältnis für mehrere Datenobjekte, d.h. eine Liste von Dokumenten, Ordner oder Instanzen anderer Objekttypen.

- ein Datenobjekt (DataObject) repräsentiert genau ein Objekt mit einer Identität (ObjectIdentity) und besteht aus einer Reihe von Attributen (Properties), den Inhalt inkl. Formatvarianten (Contents) bei Dokumenten, Beziehungen zu Ordnern, z.B. Verlinkungen (Relationship) und Rechte des aktuellen Nutzers an dem Objekt (Permissions).

- eine Objektidentität (ObjectIdentity) ist gekennzeichnet durch eine eindeutige Identifikationsnummer und Repositoryname bzw. einer Qualifikation wie z.B. wähle alle Dokumente mit den Namen „DFS Dokument” (falls die Funktion mehrere Objekte auf einmal verarbeitet!).

- Attribute (Properties) sind die Eigenschaften der Objekte (wie z.B. der Name eines Dokuments oder das Änderungsdatum). Jede Property stellt genau ein Attribut dar und hat sowohl einen Namen, einen Datentyp und auch einen oder mehrere Werte.

- Mit Inhalten sind die eigentlichen Dateiinhalte von Dokumenten inkl. dessen Formatvarianten gemeint. Dieser Inhalt kann über die Schnittstelle auch abgerufen werden.

- Beziehungen drücken z.B. die Verlinkungen eines Objekts in ein oder mehrere Ordner aus, d.h. darüber kann man z.B. die Ablageorte eines Dokuments abrufen.

-  die Rechte für ein Objekt sind nichts weiter als eine Auflistung der bekannten Basisberechtigungen (z.B. delete, write) und erweiterten Rechten (z.B. changeOwner). Da bei DFS alle Aktionen im Kontext eines konkreten Nutzers ausgeführt werden, sind damit die Rechte des aktuellen Nutzers an dem vorliegenden Objekt gemeint.

Welche Dienste und Funktionen dem Entwickler überhaupt zur Verfügung stehen, verrät Tabelle 1. Auf Dienste wie z.B. Content Intelligence Services, Collaboration Services etc. wird an dieser Stelle nicht eingegangen. Bei Fragen zu Details und Integrationsmöglichkeiten, kontaktieren Sie uns bitte gern.

Tabelle 1: Übersicht zu den bereitgestellten Diensten bei DFS

Eine Liste von Objektidentitäten wird oftmals von den Funktionen als Eingabeparameter erwartet (z.B. Löschen von Dokumenten anhand von IDs, Abruf der Attribute eines Dokuments auf Basis der ID). Als Ergebnis bekommt man meist ein Datenpaket mit einer Reihe von Datenobjekten, die dann ausgewertet werden müssen.

Die einzelnen Operationen können dabei meist durch Optionen oder Filter in ihrem Verhalten von außen verändert werden. Beim Abruf eines Dokuments ist es z.B. möglich, sich alle oder gar kein Inhalte liefern zu lassen oder auch auf bestimmte Attribute zu filtern, die dann als Ergebnis zurückgeliefert werden.

Fazit

Auf den ersten Blick bietet DFS eine große Funktionalität auf niedrigem Abstraktionsniveau. Das Datenmodell ist generisch gehalten und ermöglicht eine flexible Nutzung der mitgelieferten Dienste. Dies lässt vermuten, dass DFS ähnlich zur DFC benutzt werden kann. Warum dies nicht so ist und wie DFS überhaupt funktioniert, erfahren Sie im nächsten Blogartikel.

Möchte man beim Upgrade auf SharePoint 2010 auch gleichzeitig das Farm Sizing ändern, ist das nur beschränkt möglich. Weiterführende Informationen über die unterstützten Ziel-Topologien gibt es hier: http://technet.microsoft.com/de-de/library/cc262747%28office.14%29.aspx

Beim Upgrade von SharePoint 2003 zu SharePoint 2007 gab es drei grundsätzliche Upgrade Pfade.

• Mit der Inplace Methode wurde die neue SharePoint Version einfach über die bestehende installiert.
• Beim Gradual Upgrade wurde side by side die neue SharePoint Version installiert. Anschließend aktualisierte der Administrator nacheinander die Site Collections.
• Die Database Migration Methode setzte zu der bestehenden SharePoint 2003 Farm eine komplett neue SharePoint 2007 Farm voraus. Die Datenbanken wurden dann von der alten Farm abgehängt, an die neue wieder angehängt und anschließend aktualisiert.

Für SharePoint 2010 gibt Microsoft nur noch zwei grundsätzliche Methoden und zusätzlich zwei Hybride Methoden an. Die Inplace Upgrade Methode (Direktes Upgrade) und die Database Attach Methode (Upgrade mit Anfügen der Datenbanken). Eine Gradual Upgrade Methode ist nicht mehr verfügbar. Bevor mit dem Upgrade begonnen werden kann, müssen die PreUpgrade Schritte durchgeführt werden. Unter anderem wird mit dem STSADM Tool PreUpgradeChecker (im MOSS 2007 SP2 enthalten) die SharePoint 2007 Farm geprüft. Sie sollten auch darauf achten, dass alle Anpassungen (Webparts & Co) 64 Bit fähig sind.

Inplace Upgrade
Das Inplace Upgrade ist die einfachste Methode. Dabei wird SharePoint 2010 über die bestehende SharePoint 2007 Version installiert. Der eigentliche Upgrade Prozess wird über einen Wizard gestartet. Die Server werden während des Upgradeprozesses (sequentielle Aktualisierung) offline geschaltet. Die Vorteile dieser Methode liegen darin, dass alle Einstellungen erhalten bleiben und Anpassungen anschließend verfügbar sind. Bei Umgebungen mit tiefgehenden Anpassungen sind manuelle Schritte notwendig z.B. erneutes Compilieren. Die Nachteile liegen darin, dass die Farm während des Upgrade Prozesses nicht zur Verfügung steht und dass das Upgrade nicht rückgängig gemacht werden kann. Aus diesem Grund sollte das Upgrade auf einer zweiten Umgebung getestet werden. Für den Anwender ändert sich nach dem Upgrade erst einmal nichts. Die Webseiten bleiben im MOSS 2007 Design und müssen manuell über die „Visual Upgrade” Einstellung das SharePoint 2010 Design zugewiesen bekommen. Natürlich lässt sich das auch über Scripts automatisieren. Unter Umständen müssen die Seiten manuell angefasst werden, da sich der Seitenaufbau stark unterscheidet.

Database Attach
Database Attach bedeutet, dass man die Inhaltsdatenbanken von der bestehenden Farm abgehängt und an eine SharePoint 2010 Farm wieder anhängt. Dazu benötigt man neue Hardware und muss die SharePoint 2010 Farm komplett neu aufbauen. Die Konfiguration des alten Systems kann dabei nicht übernommen werden. In manchen Fällen ist das vielleicht nicht schlecht. Alle Anpassungen wie Sitetemplates, Webparts etc müssen in der neuen Umgebung neu installiert werden. Mehrere aus der Historie gewachsene SharePoint 2007 Farmen können bei dieser Gelegenheit gleich in einer Farm konsolidiert werden. Beim Abhängen/Anhängen der Datenbanken handelt es sich im Grunde um ein Backup und Restore. (Befehl Datenbank wiederherstellen im DB Management Studio). Bevor Sie die SharePoint 2007 Datenbanken sichern, sollten Sie die Datenbanken auf Read-Only setzen. Über stsadm -o addcontentdb -url <URL> -databasename <Datenbankname> werden die Datenbanken der Webapplikationen hinzugefügt. Auch bei dieser Methode bleiben die Webseiten im MOSS 2007 Design und müssen manuell über die „Visual Upgrade” Einstellung oder per Script das SharePoint 2010 Design zugewiesen bekommen.

Im Microsoft Technet ist das Upgrade zu SharePoint 2010 sehr umfangreich dokumentiert. Häufig werden SharePoint Umgebungen jedoch durch eine Vielzahl von Anpassungen und Eigenentwicklungen erweitert. Diese machen dann ein Upgrade kompliziert, da die Lösungen in vielen Fällen für SharePoint 2010 angepasst werden müssen. Durch die neuen Funktionen in SharePoint 2010 sollte man jedoch auch prüfen, ob man diese Eigenentwicklungen überhaupt noch benötigt oder ob sie durch SharePoint Out of the Box Features neu erstellt werden können.

Übersicht im Microsoft Technet:
http://technet.microsoft.com/de-de/sharepoint/ee517214%28en-us%29.aspx

PreUpgrade Informationen:
http://technet.microsoft.com/en-gb/library/ee833948%28office.14%29.aspx

Upgrade Methoden:
http://technet.microsoft.com/en-gb/library/cc263447(office.14).aspx

PostUpgrade Informationen
http://technet.microsoft.com/en-gb/library/cc303434%28office.14%29.aspx

Wenn Sie vor der Herausforderung stehen, Ihre SharePoint 2007 Umgebung auf SharePoint 2010 zu aktualisieren, sollten Sie schon jetzt mit der Planung beginnen. Durch die offizielle Beta Version können Sie die Upgrade Methoden in einem Testsystem evaluieren und die benötigten Ressourcen und Aufwände besser planen. Gerne bieten wir dabei unsere Unterstützung an.

Eine Erweiterung, die spezielle Funktionalitäten für die performante Massenverarbeitung beinhaltet. Zu den Zielen des High Volume Servers gehören:

• Die Minimierung von Hardware-Ressourcen
• Die Steigerung der Objekt-Verarbeitung
• Schnellerer Zugriff auf relevante Informationen in großen Repositories

Die Notwendigkeit für einen Einsatz des High Volume Servers sieht EMC in den folgenden drei Anwendungsszenarien:

• High Volume Server als Stand-alone-Umgebung für eigenständige Individualanwendungen oder Transactional Content Management Anwendungen
• Heterogene Content Server bei denen die High Volume Server Erweiterung nur für einen Teil oder von speziellen Clients der Anwendung genutzt bzw. vorausgesetzt wird
• High Volume Server als Archivierungsplattform mit Compliance-Anforderungen, bei der effiziente Speicherung und Verarbeitungsgeschwindigkeit benötigt werden

Die Performance-Verbesserung des High Volume Servers wird mit Hilfe der Light Weight SysObjects, der Batch Verarbeitung, dem Scoping und der Partitionierung erreicht.

Light Weight SysObject
Die Light Weight SysObjects teilen dokumentenbezogene Metadaten in Vater- und Kind-Objekte auf. Das Vaterobjekt speichert allgemeine Daten, die für alle Kinder identisch sind, so dass in diesen nur noch spezifische Metadaten und gegebenenfalls Content gespeichert werden muss. Dadurch wird nicht nur die Performance beim Neuanlegen gesteigert, da weniger Operationen notwendig sind, sondern auch der Speicherplatz für ein Objekt verringert. Ein Nachteil der Light Weight SysObjects ist die eingeschränkte Funktionalität, die sich z.B. durch fehlende Unterstützung von virtuellen Dokumenten oder Workflows bemerkbar macht. Jedoch ist es möglich, das Light Weight Objekt in ein normales Objekt zu transformieren, wenn die eingeschränkten Funktionen benötigt werden.

BatchProcessing
Für Anwendungen bei denen gleichzeitig eine große Anzahl ähnlicher Objekte im Repository erzeugt werden muss, bietet Batch Processing gegenüber der normalen Verarbeitung einen erheblichen Geschwindigkeitsvorteil. Die anzulegenden Objekte werden als Einheit ausgeführt, um wiederkehrende Verarbeitungsaufgaben zu eliminieren, da das Erzeugen von einzelnen Objekten eine ressourcenintensive Aufgabe ist. Alle anzulegenden Objekte werden über einen Aufruf vom Client zum Server angelegt, wie die nachfolgende Abbildung zeigt. Dadurch verringert sich der Netzwerkverkehr zwischen Client und Server. Des Weiteren wird eine schnellere Verarbeitung zwischen dem High Volume Server und der Datenbank erreicht. Die Batch-Verarbeitung wird durch das Interface „IDfBatchManager“ unterstützt, welches als eine optionale Erweiterung in der DFC Bibliothek implementiert ist.

Scoping
Eine weitere Reduzierung von Ressourcen wird durch das Scoping erzielt. Prüfungen werden beim Abfragen oder Erstellen von Objekten nur für das erste Objekt durchgeführt, so dass für weitere Objekte, die innerhalb der aktiven Session erzeugt oder abgefragt werden, redundante Überprüfungen entfallen. Innerhalb der Session werden die benötigten Informationen der ersten Abfrage zwischengespeichert, und sind so für die nachfolgenden Abfragen nutzbar. Neben dem Batch Processing wurde auch das Scoping als optionale Erweiterung in der DFC Bibliothek implementiert. Die Abbildung zeigt, dass ab der zweiten Abfrage weniger Überprüfungen für das Anlegen eines Objekts notwendig sind und dies einen Geschwindigkeitsvorteil bringt.

Data Partitioning
Das Data Partitioning hilft, die Storagekosten zu minimieren und dabei die Zugriffsgeschwindigkeit auf relevante Daten zu erhöhen. Durch die Verteilung der Datenbanktabellen eines Repositories in verschiedene Partitionen können unterschiedliche Speichermedien eingesetzt werden. Die Verteilung der Objekte sollte sich an der Zugriffshäufigkeit orientieren, so dass die Speicherung von häufig zugegriffenen aktuellen Daten auf sehr schnellen Medien und von älteren Daten, die seltener abgefragt werden, auf langsameren Medien erfolgt.

Der Einsatz des Data Partitioning erfordert besondere Objekttypen, die ein zusätzliches Attribut für die Partitionseinteilung besitzen. Auf dem Server werden die Datenbanktabellen der Repository-Objekte in einzelne Partitionen aufgeteilt. Jede Partition besitzt einen vorher festgelegten Wertebereich, so dass der High Volume Server beim Speichern eines Objekts anhand des extra Attributs die richtige Partition auswählt. Des Weiteren wurde die Abfragesprache DQL erweitert, um die Vorteile des gezielten Abfragens einer Partition zu ermöglichen. Das Partitionieren des Repositories muss nicht nur von der Datenbank (Oracle oder Microsoft SQL Server), sondern auch vom eingesetzten Client mit Hilfe der DFC Bibliothek unterstützt werden.

Ein weiteres Highlight des Data Partitioning ist das Austauschen von Partitionen. Diese Funktion ermöglicht es, eine sehr große Anzahl von Light Weight Objekten ohne die Verwendung des Content Servers in eine vorher angelegte Datenbankpartition (Offline Partition) zu schreiben. Durch einen anschließenden Neustart des Content Servers wird die gesamte Offline Partition im Repository zur Verfügung gestellt. Die Vorteile vom Partitionsaustausch liegen in der schnellen Bereitstellung von großen Datenmengen sowie der entfallenen Beanspruchung des Content Servers beim Erstellen der Objekte.

Fazit
Der High Volume Server bietet im Vergleich zum normalen Content Server einige sehr wertvolle Funktionen, die die Verarbeitungsgeschwindigkeit für große und spezielle Anwendungsfälle deutlich steigern. Darüber hinaus können durch den Einsatz von unterschiedlichen Speichermedien erhebliche Storagekosten eingespart und die Zugriffszeit auf relevante Daten reduziert werden. Jedoch unterstützen noch nicht alle Documentum Clients den vollen Funktionsumfang des High Volume Servers, so dass die Entwicklung von spezifischen Clients notwendig ist, um alle Vorteile zu nutzen. Dadurch ist zurzeit der Einsatz des High Volume Server auf einzelne Documentum Clients (My Documentum for Outlook und xCP - TaskSpace) sowie Eigenentwicklungen beschränkt.