MSDN Magazin > Home > Ausgaben > 2007 > August >  Excel Services: Entwickeln eines Berechnungsmod...
Excel Services
Entwickeln eines Berechnungsmoduls für Ihre Anwendungen
Vishwas Lele and Pyush Kumar

Themen in diesem Artikel:
  • Excel als serverbasierte Anwendung
  • Excel Services-Architektur und APIs
  • Erstellen verwalteter benutzerdefinierter Funktionen
  • Erstellen benutzerdefinierter Lösungen mit Excel Services
In diesem Artikel werden folgende Technologien verwendet:
Excel Services
Laden Sie den Code für diesen Artikel herunter: ExcelServices2007_08.exe (226 KB)
Code online durchsuchen
Organisationen verwenden Microsoft® Excel®, um komplizierte Berechnungen durchzuführen und mithilfe von Diagrammen, Pivottabellen und ähnlichen Elementen Informationen visuell darzustellen und viele andere benutzerdefinierte Aufgaben durchzuführen. Doch wenn Sie in der Vergangenheit ein Berechnungsmodul implementieren wollten, mussten Sie die Dienste eines Entwicklers in Anspruch nehmen, der mit den von Ihren Geschäftsanalysten bereitgestellten Algorithmen Code entwarf. Mit der Excel Services-Technologie in Office SharePoint® Server 2007 können Geschäftsanalysten die benötigten Berechnungsmodulformeln jetzt selbst implementieren. Dadurch werden die Implementierungskosten verringert, und die Pflege der Berechnungsalgorithmen wird einfacher als zuvor. Außerdem können mit Excel Services die benutzerdefinierten Algorithmen in einer Excel-Arbeitsmappe auf einem Webserver ausgeführt werden, sodass Benutzer von einem Remotestandort darauf zugreifen können. Wie Sie sich vorstellen können, bedeutet dies, dass viel mehr Benutzer die Software an viel mehr Standorten nutzen können.

Excel Services-Architektur
Betrachten wir, wie die Excel Services-Architektur diese Flexibilität ermöglicht. Excel Services besteht aus drei Ebenen: einem Web-Front-End, einem Anwendungsserver und einer Datenbank (siehe Abbildung 1). Die SharePoint-Inhaltsdatenbank bildet die Datenbankebene. Um das serverseitige Excel-Verhalten zu aktivieren, platzieren Sie die Arbeitsmappe an einen vertrauenswürdigen SharePoint-Standort oder in einer Netzwerkfreigabe. Einige Funktionen (z. B. zusätzliche Sicherheitsfeatures) sind nur durch SharePoint verfügbar.
Abbildung 1 Architektur der Excel-Webdienste 
Der Anwendungsserver besteht aus Diensten für Excel-Berechnungen, die für das Laden einer bestimmten Arbeitsmappe und das Durchführen aller erforderlichen Berechnungen verantwortlich sind. Arbeitsmappeninstanzen können mit externen Datenquellen verbunden werden.
Das Web-Front-End ist für das Rendern relevanter Teile der Arbeitsmappe in HTML über ein SharePoint-Webpart verantwortlich. Außerdem ist es für die Bereitstellung von Webdienst-Endpunkten verantwortlich, die Remotezugriff auf die Dienste für Excel-Berechnungen ermöglichen.
Ein wichtiger Aspekt der Excel Services-Architektur ist, dass sie in SharePoint 2007 integriert ist. Wie bereits erwähnt, muss die Arbeitsmappe innerhalb einer SharePoint-Inhaltsdatenbank gespeichert werden, um einige serverseitige Verhaltensweisen zu aktivieren. Dadurch können Content Management-Features in SharePoint wie Versionsverwaltung, Ein- und Auschecken und Sicherheitsrollen und Berechtigungen im Kontext von Excel-Arbeitsmappen genutzt werden.
In ähnlicher Weise basieren die Dienste für Excel-Berechnungen auf dem SharePoint Shared Service Provider-Modell (SSP). SSP ist eine Methode zum Verpacken von SharePoint-Funktionen als Dienst, die dadurch einfacher zu verwalten sind und auf verschiedenen Websites verwendet werden können. Demzufolge ist es möglich, eine Instanz der Dienste für Excel-Berechnungen auf mehreren SharePoint-Websites wiederzuverwenden und sie über eine SharePoint-Verwaltungssite zu verwalten.
Des Weiteren sollten Sie beachten, dass Excel Services Excel einige Einschränkungen auferlegt. Makros und nicht verwaltete codebasierte Add-Ins wie VBA-Code (Visual Basic for Applications) werden nicht von Excel Services unterstützt. Stattdessen unterstützen Excel Services verwaltete serverseitige, benutzerdefinierte Funktionen (UDF) – eine Schnittstelle, die den Aufruf benutzerdefinierter Berechnungen aus einer serverseitigen Arbeitsmappe ermöglicht.
Im weiteren Verlauf dieses Artikels werden wir uns ein UDF-Codebeispiel ansehen. Die Einschränkung bezüglich Add-Ins mit nicht verwaltetem Code kann überwunden werden, indem eine verwaltete UDF zum Wrappen von nicht verwaltetem Code erstellt wird. Die Einschränkung bezüglich der Verwendung von VBA und Makros ist hart, kann sich jedoch als Segen erweisen. Dadurch wird nämlich verhindert, dass die serverseitige Berechnungslogik zu komplex wird.

Die Excel Services-API
Betrachten wir nun die webdienstbasierte Excel Services-API, die für die Interaktion mit einer serverseitigen Arbeitsmappe verwendet wird. Dabei wird der Codeausschnitt in Abbildung 2 als Basis für die folgende Diskussion verwendet. Der Einfachheit halber wurde Code ausgelassen.
string sheetName = “Input”;
string targetWorkbookPath = “workbook.xlsx”;
Excel.Status[] outStatus;
            
// #1 Excel Service Namespace 
// using Excel = Microsoft.Office.Excel.Server.WebServices;

//#2 ExcelService 
Excel.ExcelService service = new Excel.ExcelService();

//#3 Open a session with the workbook
string sessionID = service.OpenWorkbook(targetWorkbookPath,”en-US”, 
    “en-US”, out outStatus);

// #4 Prepare the range 
Excel.RangeCoordinates rangeCoordinates = new Excel.RangeCoordinates();
rangeCoordinates.Column = 8;
rangeCoordinates.Row = 7;
rangeCoordinates.Height = 1;
rangeCoordinates.Width = 9;

object[] rangeValues = new object[rangeCoordinates.Width];
// Populate rangeValues
...

// #5 Set range values
service.SetRange(sessionID, sheetName, rangeCoordinates, 
    rangeValues, out outStatus);

// #6 Calculate the formulas in the workbook
service.CalculateWorkbook(sessionID, 
    Excel.CalculateType.CalculateFull, out outStatus);

// #7 Get the calculated values 
object[] rangeResult = service.GetRange(sessionID, 
    sheetName, rangeCoordinates, false, out outStatus);

Console.WriteLine(“Total Rows: “ + rangeResult.Length);

// #8 Close the session 
service.CloseWorkbook(sessionID, out outStatus);

Um zu beginnen, muss die Arbeitsmappe den Clients zugänglich gemacht werden. Durch die Excel Services-API, ein Teil von Microsoft.Office.Excel.Server.WebServices, kann auf jede Arbeitsmappe zugegriffen werden, die an einem Speicherort auf dem Server gespeichert wurde. Der Excel 2007-Client vereinfacht die Veröffentlichung der Arbeitsmappe durch die Veröffentlichungsfunktion. Der Vorteil bei der Verwendung der Veröffentlichungsmethode ist, dass Sie steuern können, welche Teile einer Arbeitsmappe (Tabellenblätter, Ansichten, Pivottabellen und so weiter) über die Excel Services-API zugänglich sind. Die primäre Klasse in der API ist die ExcelService-Klasse, die in Abbildung 2 gezeigt wird. Diese Klasse stellt eine serverseitige Instanz einer Arbeitsmappe im Speicher dar. Um mehreren Benutzern zu ermöglichen, gleichzeitig mit einer Arbeitsmappe zu interagieren, wurde ein sitzungsbasiertes Zugriffsmodell implementiert. Jeder Benutzer öffnet mit der OpenWorkbook-Methode der ExcelService-Klasse eine separate Sitzung mit einer Arbeitsmappe. Die OpenWorkbook-Methode gibt eine eindeutige Sitzungs-ID zurück, die mit der geöffneten Sitzung verknüpft ist. Diese Sitzungs-ID muss bereitgestellt werden, wenn nachfolgende Methoden aufgerufen werden, die mit der geöffneten Arbeitsmappe interagieren. Um innerhalb einer Arbeitsmappe einen benannten Bereich festzulegen, können Sie die RangeCoordinates-Klasse verwenden, um die Grenzen des benannten Bereichs zu definieren. SetRange übernimmt RangeCoordinates und das entsprechende Array, das Werte enthält, die als Parameter übergeben werden. Eine Variante der SetRange-Methode ist die SetRangeA1-Methode, die anstelle der von SetRange verwendeten Bereichskoordinaten die Excel-Bereichsspezifikation „A1“ verwendet. Sobald alle erforderlichen Bereichswerte angegeben wurden, kann CalculateWorkbook aufgerufen werden, um die Arbeitsmappe zu zwingen, die Formeln zu berechnen. Die jüngste CalculateWorkbook-Methode kann abgebrochen werden, indem eine CancelRequest-Methode aufgerufen wird. Mit der GetRange-Methode können Sie berechnete Werte aus einem Bereich in der geöffneten Arbeitsmappe erhalten. Sobald alle berechneten Werte abgerufen wurden, schließen Sie die Arbeitsmappensitzung mit der CloseWorkbook-Methode.
Excel Services kann erweitert werden, indem UDFs hinzugefügt werden, die ähnlich wie die integrierten Excel-Funktionen als Zellformeln zugänglich sind. Wenn Sie eine UDF erstellen möchten, müssen Sie eine Microsoft® .NET Framework-Assembly erstellen, die wenigstens eine Klasse enthält, die mit UdfClassAttribute markiert ist, sowie mindestens eine Methode, die mit UdfMethodAttribute markiert ist. Sehen Sie sich den folgenden Codeausschnitt an. Hier wird ConvertToUpper als UDF-Methode definiert. Nach der angemessenen Registrierung der UDF kann die ConvertToUpper-Funktion innerhalb einer Instanz einer Excel Services-Arbeitsmappe enthalten sein:
using Microsoft.Office.Excel.Server.Udf;

[UdfClass]
public class Util
{
    [UdfMethod]
    public string ConvertToUpper(string name)
    {
        return name.ToUpper();
    }
}
Hier wurde nur ein kleiner Teil der Excel Services-API behandelt. Weitere Details finden Sie in der MSDN®-Dokumentation.

Benutzerdefinierte Lösung mit Excel Services
Die primäre Motivation zum Entwickeln einer benutzerdefinierten Lösung besteht darin, Geschäftsanalysten zu ermöglichen, Berechnungen (z. B. finanzielle Modelle) direkt als Excel-Formeln zu verfassen. Bisher haben Geschäftsanalysten sich größtenteils auf die Dokumentierung von Algorithmen als Pseudocode in Text verlassen. Der Pseudocode wurde dann von Entwicklern in Code übersetzt. Mit Excel Services konnten einige der Einschränkungen überwunden werden, die dem Prozess des Erstellens von Formeln in Excel anhaften. Als Folge daraus wurde auch die Notwendigkeit für Entwickler beseitigt, den Pseudocode in echten Code zu konvertieren.
Die größte Herausforderung beim Verfassen von Berechnungslogik durch Laien bestand darin, ein Gleichgewicht zwischen Flexibilität und Bequemlichkeit beim Verfassen herzustellen, mit der Möglichkeit, eine widerstandsfähige Struktur durchzusetzen. Zum Bereitstellen der Struktur wurde eine Möglichkeit benötigt, eine Eingabe- und Ausgabe-„Schnittstelle“ zu definieren, die den Datenvertrag für einen Berechnungsalgorithmus darstellt. Geschäftsanalysten wären auf die benannten Bereiche beschränkt, die Teil des Datenvertrags für in die und aus der Berechnungsinstanz fließende Daten sind.
Die offensichtliche Wahl war, den Datenvertrag mithilfe benannter Zellen oder Bereichskonstrukte innerhalb von Excel zu definieren. Benannte Bereiche gewähren nicht nur das erforderliche Maß an Abstufung zum Verfassen von Berechnungen innerhalb von Excel, sie sind auch die grundlegende Datenstruktur, auf der Methoden der Excel Services-API wie SetRange und GetRange basieren. Die Herausforderung bei der Verwendung benannter Bereiche jedoch ist, dass es kein Standardformat und keine Standardsprache wie XML Schema Definition (XSD) oder Web Services Description Language (WSDL) gibt, um die Schnittstelle zu definieren. Außerdem sind benannte Bereiche (und folglich Methoden der Excel Services-API) generell typunsicher. Es gibt zum Beispiel keine Möglichkeit, die Überprüfung von Datentypen für einen bestimmten benannten Bereich durchzusetzen. Darüber hinaus gibt es keine integrierte Möglichkeit, den Vertrag flächendeckend für die Berechnungen (innerhalb von Excel) und das Excel Services-Clientprogramm durchzusetzen.
Um diese Einschränkungen zu überwinden, wurde eine benutzerdefinierte, zweiteilige Lösung entwickelt. Der erste Teil ist ein Vorcompiler für Excel, der die benannten Bereiche auf der Grundlage einer definierten Schnittstelle generieren soll. Der zweite Teil ist ein generischer Webdienstclient für Excel, der die Berechnung innerhalb einer Arbeitsmappe aufruft, während er an der Schnittstelle festhält.

Der Vorcompiler für Excel
Die XML-Schemadefinition mit ihrem gesamten semantischen Reichtum und ihrer Einfachheit schien die ideale Wahl zum Definieren der Schnittstelle. Wir haben uns dafür entschieden, die XML-Schemakonstrukte zu verwenden, um die Eingabe- und Ausgabeverträge zu definieren. Als Nächstes wurde eine Möglichkeit benötigt, das XML-Schema in benannte Bereiche zu übersetzen. Zunächst wurde die Möglichkeit erwogen, das mit Excel 2003 eingeführte XMLMap-Feature zu verwenden. XMLMap lässt zu, dass Zellen innerhalb von Excel den Elementen eines importierten XML-Schemas zugeordnet werden. Leider steht das XMLMap-Feature Excel Services nicht zur Verfügung. Die Alternative war also, die benannten Bereiche innerhalb einer Excel-Arbeitsmappe zu erstellen. Wir haben eine Vorcompilerkomponente entwickelt, die auf der Grundlage des Schemas eine Arbeitsmappenvorlage mit den erforderlichen benannten Bereichen generiert hat. Die generierte Arbeitsmappenvorlage umfasst drei Tabellenblätter: je eines für Eingabe, Ausgabe und Berechnung. Das Tabellenblatt für die Eingabe enthält benannte Bereiche, die der Eingabe der Berechnung entsprechen. In ähnlicher Weise enthält das Tabellenblatt für die Ausgabe benannte Bereiche, die der Ausgabe der Berechnung entsprechen. Im Tabellenblatt für die Berechnung werden die Berechnungen platziert (siehe Abbildung 3).
Abbildung 3 Tabellenblätter für Eingabe, Berechnung und Ausgabe in der Arbeitsmappe (Klicken Sie zum Vergrößern auf das Bild)
Wie bereits erwähnt, stehen für Excel Services keine Programmierkonstrukte wie Schleifen zur Verfügung. Der Vorcompiler kompensiert solche Einschränkungen, indem die XML-Felder für die Eingabe in ein Format transformiert werden, das ohne Bedarf an komplexen Programmierkonstrukten zugänglich ist. Auflistungen von XSD-Elementen beispielsweise können in Dimensionen des benannten Bereichs transformiert werden. Abbildung 4 stellt einen XSD-Codeausschnitt dar, der Teil des Eingabedatenvertrags für ein Berechnungsmodul ist.
<?xml version=”1.0” encoding=”utf-8” ?>
<xs:schema id=”Input” ...>
  <xs:complexType name=”TypeA”>
    <xs:sequence>
      <xs:element name=”ValueA1” type=”xs:int”  minOccurs=”0” />
      <xs:element name=”ValueA2” type=”xs:int” minOccurs=”0” />
    </xs:sequence>
    <xs:attribute name=”RangeHeight” type=”xs:int” default=”1” />
    <xs:attribute name=”RangeWidth” type=”xs:int” default=”10” />

  </xs:complexType>
  <xs:complexType name=”InputType”>
    <xs:sequence>
      <xs:element name=”InputElementA” type=”TypeA”    />
      <xs:element name=”InputElementB” type=”TypeB”    />
    </xs:sequence>
  </xs:complexType>
  <xs:element name=”InputDataset” type=”InputType” msdata:IsDataSet=”true” />
</xs:schema>

Die Elemente „TypeA“ und „TypeB“ sind Teil der Eingabe für die Berechnung. Beachten Sie die benutzerdefinierten Attribute „RangeHeight“ und „RangeWidth“, die die Dimensionen der benannten Bereiche definieren. Der Vorcompiler verwendet diese Informationen, um die Dimensionen der benannten Bereiche zu generieren. Der Vorcompiler kann auch Indexfelder in getrennte Spalten dereferenzieren, wobei jede Spalte einen Indexwert darstellt.
Ein bemerkenswerter Aspekt des Vorcompilers ist die Möglichkeit, die vorhandenen Berechnungen beizubehalten, während die Tabellenblätter für die Ein- und Ausgabe neu generiert werden. Wie in Abbildung 5 dargestellt, ist die Entwicklung eines Berechnungsalgorithmus ein iterativer Prozess. Geschäftsanalysten und Entwickler arbeiten zusammen, um den anfänglichen Datenvertrag zu definieren. Im Verlauf der Entwicklung der Arbeitsmappe müssen die Eingabe- und Ausgabeverträge u. U. geändert werden, und die Arbeitsmappe muss neu generiert werden, damit diese Änderungen übernommen werden. Der Vorcompiler unterstützt eine solche iterative Entwicklung, indem er das Tabellenblatt für Berechnungen beibehält, während die Arbeitsmappe neu generiert wird.
Abbildung 5 Generieren einer Arbeitsmappe mit dem Vorcompiler 
Das Tabellenblatt für die Eingabe, das in Abbildung 3 gezeigt wird, enthält vorgenerierte benannte Bereiche. Das Tabellenblatt für Berechnungen enthält Berechnungen, die auf die benannten Bereiche verweisen, die in dem Tabellenblatt für die Eingabe definiert sind. Das Tabellenblatt für die Ausgabe wiederum verweist auf die Berechnungen von dem Tabellenblatt für die Berechnungen.

Der Webdienstclient für Excel
Die primäre Rolle des Webdienstclients für Excel besteht darin, mit der Excel Services-API Berechnungen innerhalb der Arbeitsmappe aufzurufen. Dadurch interpretiert der Client den auf XSD basierenden Eingabevertrag und ordnet die Schemaelemente entsprechenden benannten Bereichen zu. Sobald die Berechnung abgeschlossen ist, ordnet der Client die benannten Bereiche der Ausgabe wieder einem auf XSD basierenden Ausgabevertrag zu. In Abbildung 6 ist die Rolle des Webdienstclients für Excel dargestellt. Ein typisiertes DataSet (auf dem Eingabeschemavertrag basierend) wird als Eingabe übergeben. Daten innerhalb des DataSet werden benannten Eingabebereichen zugeordnet. Sobald die Berechnung abgeschlossen ist, wird mit den benannten Ausgabebereichen das Ausgabe-DataSet aufgefüllt. Der Webdienstclient für Excel ist verantwortlich für die Anwendung der Regeln, die für die Vorcompiler definiert werden. Es ist außerdem möglich, benutzerdefinierte Datentransformationen einzufügen, um die zuvor genannte Zuordnung zwischen XSD und benannten Bereichen zu verändern. Erinnern Sie sich an unsere frühere Diskussion über die Notwendigkeit, den Mangel an Programmierkonstrukten zu kompensieren, die Autoren von Arbeitsmappen zur Verfügung stehen. Benutzerdefinierte Datentransformationen lassen zu, dass Zuordnungen verändert werden, um Geschäftsanalysten das Verfassen von Berechnungslogik zu erleichtern.
Abbildung 6 Aufrufen des benutzerdefinierten Berechnungsmoduls 

Detaillierte Untersuchung des Codes
Die Lösung, die wir erstellt haben, besteht aus vier Projekten. Im Projekt „PreCompiler“ ist der gesamte Code zum Generieren einer Arbeitsmappe mit den erforderlichen benannten Bereichen untergebracht, die auf dem Eingabe- und dem Ausgabeschema basieren. Dabei werden die oben genannten benutzerdefinierten Attribute wie RangeHeight beim Generieren der benannten Bereiche berücksichtigt. Das Projekt „PreCompiler“ wiederum verlässt sich beim Generieren der Arbeitsmappe auf SpreadsheetML (ein auf XML basierender Dialekt, mit dem Informationen innerhalb einer Tabelle dargestellt werden). Das Projekt „SpreadsheetML“ enthält einfache Klassen, die die SpreadsheetML-Komponenten wie Arbeitsmappe, Arbeitsblatt und so weiter wrappen.
Bei dem Projekt „Client“ handelt es sich, wie der Name schon sagt, um Code für den Webdienstclient für Excel. Damit werden die Werte für die benannten Eingabebereiche festgelegt, die Arbeitsmappe wird zum Neuberechnen gezwungen, und die Werte für benannte Ausgabebereiche werden abgerufen. Sie werden sich erinnern, dass wir die Notwendigkeit erörtert haben, die Daten zu transformieren, um Geschäftsanalysten die Entwicklung der Berechnungen zu erleichtern. Damit die Datentransformation für jedes Berechnungsmodul angepasst werden kann, wurde die Datentransformationslogik externalisiert, indem eine IDataTransformer-Schnittstelle definiert wurde:
public interface IDataTransformer 
{
    object    getRangeData(string RangeName);
    object[]  getRangeData(string RangeName, int width);
    object[,] getRangeData(string RangeName, int width, int height);

    string getInputSchema();
    string getOutputSchema();

    string getInputSchemaPrefix();
    string getOutputSchemaPrefix();        
}
Der Name einer Assembly, die eine Implementierung der IDataTransformer-Schnittstelle enthält, wird als Eingabe an das Clientprogramm übergeben. Das Clientprogramm wiederum ruft die entsprechenden Methoden für die Klasse auf, die die IDataTransformer-Schnittstelle implementiert. Auf diese Weise erhält das Clientprogramm die Werte, mit denen die benannten Bereiche aufgefüllt werden. Die Implementierungslogik innerhalb der IDataTransformer-Methoden ist dafür verantwortlich, die Daten innerhalb des Eingabe-DataSet in entsprechende benannte Bereichswerte zu konvertieren. Zum Beispiel müssen u. U. einige Zeilen aus einem DataTable-Element gefiltert werden, bevor die entsprechenden benannten Bereiche aufgefüllt werden. Oder aber die Zeilen innerhalb des DataTable-Elements müssen sortiert werden, bevor sie an die Arbeitsmappe übergeben werden. All diese Anforderungen an die Datentransformation können mit der IDataTransformer-Schnittstelle erfüllt werden.
Eine weitere Klasse, die an dieser Stelle erläutert werden sollte, ist ExcelServiceFacade. Diese Klasse verbirgt die Details der Excel Services-API vor dem Aufrufenden. Die andere wichtige Funktion dieser Klasse ist, einzelne SetRange-Aufrufe zu einem zusammengefassten SetRange-Aufruf zu kombinieren. Dies ist von entscheidender Bedeutung zum Verringern der Netzwerkwartezeiten, da jeder Aufruf von SetRange einen Roundtrip zum Server verursacht. Durch Offenlegung eines lokalen SetRange-Aufrufs, der letzten Endes in einen zusammengefassten SetRange-Aufruf konvertiert wird, kann ExcelServiceFacade die Antwortzeiten drastisch verbessern. In Abbildung 7 ist der relevante ExcelServiceFacade-Code dargestellt. Die ExcelServiceFacade-Klasse unterhält einen internen Puffer, der jedes Mal angefügt wird, wenn ein „lokaler“ SetRange-Aufruf erfolgt. Sobald alle eingegebenen benannten Bereiche aufgefüllt sind, wird der interne Puffer als Teil eines einzelnen Aufrufs an den Server gesendet. Beim Abrufen benannter Ausgabewerte nach Abschluss der Berechnung wird eine ähnliche Methode verwendet. Statt die Werte der benannten Ausgabebereiche einzeln abzurufen, rufen wir einfach alle Werte auf dem Tabellenblatt für die Ausgabe auf einen Schlag ab.
public class ExcelServiceFacade
{
    ...
    
    public void OpenWorkbook()
    {
        if (this.SessionID.Equals(String.Empty))
        {
            Status[] status = null;
            this.Excel.Credentials = 
                System.Net.CredentialCache.DefaultCredentials;
            this.m_SessionID = this.Excel.OpenWorkbook(
                m_Url, CULTURE, CULTURE, out status);
        }        
    }

    public void CalculateWookbook()
    {
        RangeCoordinates coorInput = new RangeCoordinates();
        coorInput.Row = 0;
        coorInput.Column = 1;
        coorInput.Width = 25;
        coorInput.Height = m_RowIndex;

        // Set Range
        object[] inputValues = (object[])
            m_Input.ToArray(typeof(object[]));
        SetRange(“Input”, coorInput, inputValues);

        this.Excel.CalculateWorkbook(
            this.SessionID, CalculateType.CalculateFull);
    }
}


Leistung und Skalierbarkeit
Die tatsächliche Ausführung der Berechnungen innerhalb der Arbeitsmappe ist sehr schnell. In einem unwissenschaftlichen Test, durchgeführt mit einer Arbeitsmappe, die einen nicht trivialen Satz von Berechnungen mit nahezu 1000 benannten Bereichen enthält, lag die Antwortzeit unter einer Sekunde. Der Großteil dieser Zeit wurde für Roundtrips zum Excel-Server aufgewendet. Während die Belastung des Systems hinsichtlich der Komplexität der Berechnung und der Anzahl gleichzeitiger Ausführungen zunimmt, kann die Lösung skaliert werden, indem die von Excel Services angebotenen verschiedenen Topologieoptionen wirksam eingesetzt werden. Verschiedene Topologieoptionen ermöglichen Ihnen zu wählen, wo die einzelnen logischen Excel Services-Schichten (Darstellung, Anwendung und Datenbank) platziert werden. Bei kleineren Setups (hauptsächlich für Testzwecke) ist es möglich, alle drei Schichten auf einem einzelnen Server bereitzustellen. Bei einem mittleren Setup können die Darstellungs- und die Anwendungsschicht auf einem einzelnen Server und die Datenbankschicht auf einem separaten Server installiert werden. Bei großen Setups können Sie jede der drei Schichten auf getrennten Servern installieren. Zusätzlich können Sie die Darstellungsschicht ausskalieren, indem Sie mithilfe eines Netzwerklastenausgleichmoduls weitere Server hinzufügen. Die Anwendungsschicht, die auch die Dienste für Excel-Berechnungen einschließt, kann ebenfalls mit Lastenausgleichsschemas ausskaliert werden, die vom SSP-Framework unterstützt werden. In Abbildung 8 ist ein großes Setup dargestellt, in dem jede Schicht auf einem getrennten Server installiert ist. Darüber hinaus werden die Darstellungs- und die Anwendungsschicht mit Lastenausgleichsschemas ausskaliert.
Abbildung 8 Großes Setup für Excel-Webdienste 
Für rechnerisch intensive Arbeitslasten können Excel Services auch mit dem Compute Cluster Server kombiniert werden, um nahtlos Arbeit an Computeknoten zu verteilen. Dies ist in Abbildung 9 dargestellt.
Abbildung 9 Hochleistungssetup für Excel Services 
Wie Sie sehen können, ist eine benutzerdefinierte Lösung zum Implementieren von Berechnungsmodulkomponenten, die Excel Services verwenden, ein Segen für die Produktivität. Sie ermöglicht Ihnen, Ihren Benutzern überall Zugriff auf benutzerdefinierte Arbeitsmappenfunktionen bereitzustellen. Darüber hinaus entfällt die Notwendigkeit, die Logik von einem Entwickler implementieren zu lassen, und Sie können Ihre Lösung nach Bedarf skalieren. Versuchen Sie es! Wir sind sicher, Sie werden die höhere Flexibilität und Produktivität genießen, die Sie erzielen werden. Weitere Informationen finden Sie in der Randleiste „Ressourcen“.

Vishwas Lele ist CTO bei Applied Information Sciences (AIS) in Reston, VA. Er unterstützt Unternehmen beim Planen, Entwerfen und Implementieren von Unternehmenslösungen, die auf Microsoft .NET-Technologien basieren. Vishwas ist Microsoft Regional Director für das Gebiet Washington DC. Er ist unter vlele@acm.org erreichbar.

Pyush Kumar ist Lead Systems Architect für Watson Wyatt Worldwide. Zu seinen jüngsten Arbeiten zählen Rastercomputing und große Softwareentwurfsprojekte für .NET Framework. Er ist unter pyush.kumar@watsonwyatt.com erreichbar.

Page view tracker