Meer informatie

In Office 2003 is speciaal nadruk gelegd op de ontwikkeling van een werkruimte voor samenwerking. Hiertoe zijn diverse wijzigingen aangebracht in de manier waarop in Office 2003 webinhoud wordt verwerkt. Dankzij deze wijzigingen kunnen weboplossingen worden ontwikkeld waarmee Office-documenten volledig compatibel zijn met het Office 2003-systeem. In dit artikel worden deze wijzigingen vanuit een technische invalshoek beschreven. De wijzigingen bieden betere ontwerpfuncties voor de volgende webservers die Office 2003 ondersteunen:

• Microsoft Windows SharePoint Services
• Microsoft SharePoint Portal Server
• Microsoft Exchange-webarchief

Opmerking De term 'Office' heeft betrekking op de volgende producten:

• Microsoft Office Word 2003
• Microsoft Office Excel 2003
• Microsoft Office PowerPoint 2003

De term 'document' heeft betrekking op elk bestand dat of elke sjabloon die kan worden geopend in Word 2003, Excel 2003 of PowerPoint 2003, ongeacht de bestandsindeling.

Hyperlinks maken in Office 2003 met behulp van HLINK en URLMON

Net als in eerdere versies van Office, wordt in Office 2003 de werking van hyperlinks geïmplementeerd met behulp van vrij toegankelijke OLE-interfaces van het onderdeel URL Moniker (Urlmon.dll) van Internet Explorer. Met de API van URLMON kan een URL-bron in Office als een willekeurige OLE-koppelingsbron worden behandeld. Bovendien bevat de URLMON API methoden voor asynchrone navigatie, omleiding en het delen van inhoud tussen processen.

Voor het verwerken van de navigatiegeschiedenis en achterwaartse compatibiliteit, worden in Office de openbare interfaces van Microsoft Hyperlink Library (Hlink.dll) gebruikt om hyperlinks te maken, te binden en te verplaatsen. HLINK is de wrapper op hoog niveau voor de functies die worden gebruikt door URLMON. Met HLINK beschikken Office-toepassingen over een gemeenschappelijke omgeving waarin de verwerking van de basistaken van hyperlinks plaatsvindt.

Office-documenten openen vanuit Internet Explorer

Als u op een webpagina in Internet Explorer klikt op een hyperlink naar een Office-document, navigeert de hostomgeving met behulp van URLMON naar de bron van de hyperlink. URLMON downloadt de inhoud van het bestand met behulp van een HTTP GET-opdracht. Nadat URLMON de bron heeft ontvangen, zoekt URLMON op een van de volgende drie locaties naar het inhoudstype:

• Het gekoppelde MIME-type dat is opgegeven in de HTTP-header.
• De CLSID die is opgeslagen in een gestructureerd document.
• De bestandsnaamextensie, als deze is opgenomen in de URL-reeks.

Als het type hoort bij een Office-toepassing, maakt URLMON een OLE-versie van de doeltoepassing. URLMON vraagt de OLE-versie de inhoud te laden met behulp van de IPersistMoniker-interface van het OLE-object. URLMON verzendt de URL-moniker die door URLMON voor de bron wordt gemaakt naar Office. Office verpakt de URL-moniker in een nieuw HLINK-object. Nadat de URL-moniker aan het HLINK-object is gekoppeld, kan het bestand in Office worden geladen en weergegeven voor de gebruiker.


Het hele proces van het laden van webinhoud via een moniker-interface en vervolgens het binden van de webinhoud met HLINK en URLMON, valt buiten het bestek van dit artikel. Zie de documentatie op de website van MSDN (Microsoft Developer Network) voor meer informatie over het programmeren van dit proces.


Klik op het volgende artikelnummer in de Microsoft Knowledge Base voor meer informatie:
Deze benadering heeft één belangrijk nadeel. De URL-monikers die bij Internet Explorer worden geleverd, hebben meestal het kenmerk Alleen-lezen. U kunt inhoud weliswaar openen en wijzigen, maar u kunt de gewijzigde inhoud niet opslaan op de oorspronkelijke server. Als u de inhoud weer opslaat in de opslagruimte die wordt geleverd door de moniker, worden de wijzigingen toegepast op de inhoud van de cache voor tijdelijke internetbestanden van Internet Explorer. De wijzigingen worden echter niet toegepast op de inhoud op de oorspronkelijke webserver. Als oplossing voor dit nadeel is het concept van de publicatie-moniker geïntroduceerd in Office 2000 en latere versies.

Lees- en schrijftoegang voor een URL-moniker instellen met MSDAIPP

Sinds de introductie van Office 2000 zijn de functies van URLMON uitgebreid met ondersteuning van volledige schrijftoegang tot een publicatieserver waarop FrontPage-serverextensies of de HTTP 1.1-opdrachtextensies voor het WebDAV-protocol (Web Distributed Authoring and Versioning) worden ondersteund.

De ondersteuning van volledige schrijftoegang wordt gerealiseerd door middel van een protocolprovider-extensie naar URLMON. Deze protocolprovider-extensie maakt binding mogelijk via het onderdeel Microsoft OLE-databasebron voor Internet Publishing (Msdaipp.dll). Met behulp van een set vlaggen naar URLMON, kan een host binding aanvragen met behulp van een gespecialiseerd URL-monikertype dat gebruikmaakt van MSDAIPP. In Office wordt dit een publicatie-moniker genoemd. De publicatie-moniker maakt gebruik van MSDAIPP voor het rechtstreeks openen en opslaan van inhoud op de server. Dit is een belangrijke stap in de uitbreiding van URLMON-functies.

Er is echter een nadeel. Het onderdeel MSDAIPP maakt gebruik van de eigen sessie van de Windows Internet (WININET) API, niet de sessie die wordt gebruikt door Internet Explorer zelf. Om die reden zijn niet-vastgelegde sessiegegevens, zoals servercookies, niet beschikbaar in verzoeken van MSDAIPP. Daarom is voor sommige servers een nieuwe verificatie of terugbladeren naar de URL nodig, voordat MSDAIPP met die servers kan communiceren. Ook om ontvangst van 'verouderde' gegevens te voorkomen die door een andere gebruiker kunnen zijn gewijzigd, haalt MSDAIPP de webinhoud opnieuw op na eerst de webinhoud te hebben vergrendeld voor schrijftoegang. Vervolgens wordt een tweede HTTP GET-verzoek of een tweede FPSE POST-verzoek om documentinhoud naar de webserver verzonden.

Om dit probleem te omzeilen is een andere benadering geïntroduceerd in Office 2000 Service Release 1. In plaats van de inhoud tijdens het laden te binden met een publicatie-moniker, bindt Office het document met behulp van de normale alleen-lezen URL-moniker die wordt geleverd bij Internet Explorer. Wanneer u het bestand wilt opslaan, wordt in Office overgeschakeld naar de publicatie-moniker om opnieuw te kunnen opslaan op de oorspronkelijke server, als op de server webpublicaties worden ondersteund. Als een nieuwe verificatie is vereist vanwege de wijziging in de sessie, wordt u gevraagd om referenties op te geven bij het opslaan in plaats van bij het openen. Als u het bestand alleen wilt lezen zonder wijzigingen op te slaan, wordt in Office de kostbare overschakeling naar een publicatie-moniker vermeden. Ook wordt in Office geen serververgrendeling op de bron geplaatst. Dit is een voorlopige oplossing.


Voor meer informatie over enkele wijzigingen die in Office 2000 Service Release 1 zijn geïntroduceerd om de effecten te verminderen van het openen van webdocumenten door de context van de publicatie-moniker te gebruiken, klikt u op de volgende artikelnummers in de Microsoft Knowledge Base:

De nadelen van de oplossingen in eerdere Office-versies herkennen

De tussenoplossing die is gebruikt in Office 2000 Service Release 1 en in Office XP is goed geschikt voor het bladeren in documenten en voor het opslaan van deze documenten op de server. Deze tussenoplossing heeft echter nadelen. De nadelen gaan zwaar wegen als webontwikkelaars betere webbeheersystemen voor documenten ontwikkelen die moeten zorgen voor naadloze integratie met Microsoft Office.

Het belangrijkste nadeel is dat het overschakelen naar de andere context pas gebeurt op het moment dat een gebruiker een document opslaat of een expliciete actie uitvoert waarvoor schrijftoegang nodig is. De documentbron is niet vergrendeld en terwijl de eerste gebruiker het bestand heeft geopend, kan het bestand worden gewijzigd door een andere gebruiker of een ander proces. Als de eerste gebruiker het bestand opslaat, gaan de wijzigingen van de tweede gebruiker verloren. Ook kan het gebeuren dat de eerste gebruiker moet beslissen de wijzigingen van anderen te wissen, zonder te weten wat door de anderen is gewijzigd.

Een ander nadeel is dat de auteursmachtigingen van de gebruiker onbekend zijn totdat wordt overgeschakeld naar de andere context. De gebruiker weet tot aan het moment dat hij opdracht geeft om het bestand op te slaan niet dat hij daartoe geen machtiging heeft. De gebruiker moet bericht krijgen dat hij geen machtiging heeft het bestand op te slaan voordat hij het bestand opent voor bewerking. Dit nadeel heeft geleid tot de oplossing die is geïmplementeerd in Office 2000 Service Release 1.

Gewijzigde verwerking van hyperlinks in Office 2003

Er is een groeiend aantal gebruikers dat Office gebruikt als een front-endtoepassing voor samenwerking aan documenten via HTTP-intranetten. De nadelen van de voorgaande oplossing zijn voor hen zwaarwegend. Er zijn dus wijzigingen noodzakelijk, zodat het verschil tussen een gedeeld document en een document in de bladermodus duidelijk te zien is. In Office 2003 worden nieuwe functies voor de verwerking van hyperlinks geïntroduceerd waarmee de nadelen worden omzeild.

Microsoft Office-protocoldetectie gebruiken

Wanneer een Office-toepassing een verzoek ontvangt om een webbron te openen, moet de Office-toepassing de volgende afwegingen maken over hoe de webbron wordt geopend:

• De bron openen met het kenmerk Alleen-lezen uit de inhoud die is gedownload met Internet Explorer. Deze inhoud wordt geopend in bladermodus.
• De bron openen met het kenmerk Lezen/schrijven met een documentvergrendeling op de server voor exclusieve toegang. Deze inhoud wordt geopend in bewerkingsmodus.

Hoe de webbron wordt geopend, kan worden vastgesteld door te kijken naar het pad van de map met het document en naar de mogelijkheden van de server die het pad beheert. De mogelijkheden die op de server worden ondersteund, worden in Office 2003 opgevraagd met een OPTIONS-standaardopdracht van HTTP 1.1 Met de OPTIONS-opdracht wordt nagegaan welke opdrachten en welke methoden op de server worden ondersteund voor de map met het document. De serveridentificatie verloopt volgens de regels die worden vermeld in RFC 2616. Een HTTP 1.1-compatibele webserver beantwoordt de OPTIONS-opdracht met een lijst van de ondersteunde methoden voor de URI (Uniform Resource Identifier). Office evalueert het antwoord en zoekt vervolgens naar het volgende:

• Protocol voor het schrijven van webpagina's
  
  Als de respons van de server een MS-AUTHOR-VIA-headerwaarde of een lijst met methoden bevat die consistent zijn met WebDAV (Distributed Authoring and Versioning), wordt in Office aangenomen dat het document weer op de oorspronkelijke webserver kan worden opgeslagen met het opgegeven protocol.
  
  De protocollen die op dit moment beschikbaar zijn, zijn WEC (Web Extender Client) en WebDAV. Als op de server geen protocol beschikbaar is, wordt ervan uitgegaan dat het bestand het kenmerk Alleen-lezen heeft. De client kan een opdracht Opslaan als uitvoeren om lokaal een kopie op te slaan. Een kopie kan echter niet worden opgeslagen in de oorspronkelijke map van het bestand.
• Type webserver
  
  Office probeert tevens het type webserver vast te stellen. Deze vaststelling is gebaseerd op headergegevens die worden opgehaald met de OPTIONS-aanroep. Met name wordt in Office gezocht naar headerwaarden die duiden op communicatie met een SharePoint-documentbibliotheek of een Exchange-webarchiefmap. Als communicatie wordt aangetroffen, wordt in Office aanvullende communicatie uitgevoerd naar de server om de volgende functies voor websamenwerking in te schakelen:
  • Webdiscussies
  • Updates van takenlijsten
  • Document uitchecken
  • Document inchecken
  De voorgaande functies voor samenwerking op het web worden ondersteund op bepaalde typen webservers. Office herkent het type webserver aan de volgende headers:
  • MicrosoftSharePointTeamServices
  • MicrosoftTahoeServer
  • MicrosoftOfficeWebServer
  • MS-WebStore

Als op de webserver verificatie nodig is om het OPTIONS-verzoek te kunnen voltooien, kunt u worden gevraagd om referenties om de aanroep te kunnen voltooien. Nadat de aanroep is voltooid, worden de opgehaalde gegevens opgeslagen in uw registercomponent zodat de aanroep voor deze map niet hoeft te worden herhaald. De cache voor Office-protocoldetectie bevindt zich onder de volgende registersleutel:

HKEY_CURRENT_USER\Software\Microsoft\Office.0\Common\Internet\Server Cache

De sleutel Server Cache bevat subsleutels voor elke geopende webmap die een OPTIONS-aanroep heeft beantwoord. Elke vermelding bevat de volgende waarden die de juiste instelling voor de desbetreffende map hebben:

• Protocol
  
  Dit is een 32-bits DWORD-waarde voor het te gebruiken protocol voor het schrijven van webpagina's. De momenteel gedefinieerde waarden zijn:
  • 0 voor alleen-lezen HTTP.
  • 1 voor een webmap waarvoor WEC of FPSE is ingeschakeld.
  • 2 voor een webmap waarvoor DAV of uitgebreide DAV is ingeschakeld.
• Type
  
  Dit is een DWORD-waarde die het type server voor samenwerking aan webdocumenten aangeeft waar de map wordt beheerd. De momenteel gedefinieerde waarden zijn:
  • 0 voor 'geen samenwerking'
  • 1 voor SharePoint Team Server
  • 2 voor Exchange 2000 Server
  • 3 voor SharePoint Portal 2001 Server
  • 4 voor SharePoint 2001 uitgebreide map
  • 5 voor Windows SharePoint Server en SharePoint Portal 2003 Server
• Expiration
  
  Dit is een 64-bits QWORD-waarde die een verlooptijd aangeeft. De waarde is een Win32 FILETIME-structuur die de verlooptijd bevat in UTC-notatie (Universal Time Coordinate). Na het verstrijken van de verlooptijd verzendt Office query's naar de webserver met een volgende OPTIONS-aanroep om te controleren of de serverconfiguratie niet is gewijzigd sinds de laatste keer dat de waarden in de cache zijn opgeslagen. De lengte van de verlooptijd wordt bepaald op basis van een willekeurige selectie. De verlooptijd wordt gewoonlijk ingesteld op twee weken of langer.
  
  Belangrijk De registersleutel dient alleen ter informatie. Bewerk niet rechtstreeks de registersleutel of de registerwaarden. Office verwijdert periodiek de cache. De opgeslagen informatie heeft daarom een tijdelijk karakter.

Het maximum aantal vermeldingen in de cache kan worden ingesteld door de MaxCount-registerwaarde onder dezelfde Server Cache-sleutel. Office verwijdert oude vermeldingen om ruimte te maken als het maximum aantal is bereikt. Als geen ruimte kan worden vrijgemaakt, wordt het resultaat van de OPTIONS-aanroep niet in de cache opgeslagen.

Bekende problemen veroorzaakt door Office-protocoldetectie

Met Office-protocoldetectie wordt het belangrijkste probleem opgelost, namelijk bepalen of een document op de server moet worden geopend als Alleen-lezen of als Lezen/schrijven. Office-protocoldetectie brengt echter andere, nieuwe problemen met zich mee. De volgende problemen doen zich voor als neveneffect van het huidige ontwerp:

• Office-protocoldetectie maakt gebruik van een standaard HTTP 1.1 OPTIONS-opdracht. Webservers waarop deze opdracht niet kan worden verwerkt, ondersteunen geen volledige lees/schrijftoegang in Office 2003. Dit is een bekend gevolg van het ontwerp.
• U kunt om verificatiegegevens worden gevraagd wanneer u Office-bestanden opent. Dit probleem doet zich voor als op de webserver verificatie nodig is voor de verwerking van een OPTIONS-aanroep naar de URI van de map. Om dit probleem te vermijden, kunnen doorgaans wijzigingen in de serverconfiguratie worden aangebracht. Hierbij krijgen anonieme gebruikers een leesmachtiging voor de map. Leesmachtigingen worden ook wel lijstmachtigingen genoemd. U wordt om verificatiegegevens gevraagd als op de server verificatie is vereist.
• U kunt bij het openen van het bestand worden gevraagd om een clientcertificaat of een trust-a-server-certificaat te selecteren. Dit wordt ook gevraagd als u het certificaat al eerder hebt geselecteerd in Internet Explorer voor dezelfde navigatie. Omdat Office een nieuw verzoek om verwerkingsruimte naar de server stuurt, wordt elke keer een nieuwe sessie gemaakt. De nieuwe sessie kan extra beveiligingswaarschuwingen of extra prompts weergeven om de OPTIONS-aanroep te kunnen voltooien.
• Cookiegegevens die voor het ophalen van het document worden gebruikt, worden niet gebruikt in het OPTIONS-verzoek. Als op de server rechtstreekse aanroepen van de URL van de map zonder deze cookiegegevens niet zijn toegestaan, wordt de OPTIONS-aanroep mogelijk niet goed uitgevoerd. Als dit probleem optreedt, kan de gebruiker herhaaldelijk om verificatiegegevens worden gevraagd, terwijl de gebruiker deze gegevens niet kan verstrekken. Dit komt niet omdat de verificatiegegevens ontbreken. Het wordt veroorzaakt door ontbrekende sessiecookies voor de webserver. Het probleem doet zich specifiek voor op bepaalde webservers die afhankelijk zijn van cookiegegevens in plaats van verificatiegegevens, of die afhankelijk zijn van cookiegegevens én verificatiegegevens.
• Er is sprake van een bekend probleem met netwerkconfiguraties waarin CSS-taakverdeling (Cisco Content Server Switch) met niveau 5-filtering in de intranetomgeving wordt gebruikt. De CSS-software verwerkt de OPTIONS-opdracht van HTTP 1.1 niet goed. De CSS-software stuurt de oproep niet door naar de webserver. Ook stuurt de CSS-software geen antwoord naar de client waarin een fout wordt gemeld en de TCP-verbinding wordt niet afgesloten.
  
  Omdat het TCP-pakket niet door de server wordt bevestigd, gaat de client ervan uit dat het bericht niet op de server is ontvangen. De client stuurt het bericht dus opnieuw. Office gaat door met het verzenden van dit bericht en het wachten op antwoord, totdat een time-out voor de TCP-verbinding optreedt. Zo kan het gebeuren dat een client vastloopt wanneer een Office-bestand wordt geopend. De Office-toepassing wacht op antwoord van de server. Het antwoord van de server wordt nooit ontvangen omdat de CSS-taakverdeling het TCP-pakket laat vallen.
  
  Dit probleem is bekend bij Cisco. Cisco werkt aan een update waarmee dit probleem wordt opgelost. U kunt dit probleem zonder de update omzeilen door het CSS-filterniveau in te stellen op 3 of 4. U kunt ook de taakverdeling overslaan door de URL die wordt geopend te wijzigen, zodat de URL rechtstreeks verwijst naar de webserver waarop de inhoud is opgeslagen.

De voordelen van Office-protocoldetectie wegen ruimschoots op tegen de bekende nadelen. De problemen zullen na verloop van tijd minder worden. Wij blijven werken aan de twee laatste problemen, zodat oplossingen beschikbaar zijn als het bestaande netwerkontwerp niet kan worden aangepast. Wij zijn ervan overtuigd dat het gebruik van Office-protocoldetectie de juiste strategie voor de lange termijn is voor samenwerking op het web.

HTTP-conversie voor UNC-redirectorbestanden

Clients waarop Windows XP Professional wordt uitgevoerd, kunnen Netwerklocaties maken naar DAV-webmappen met behulp van de webclient-service. De webclient-service wordt ook wel WebDAV-client-redirector genoemd. Met deze webclient-service kunnen DAV-mappen worden weergegeven als UNC-shares.

Een toepassing kan het bestand openen, bewerken en opslaan, omdat toepassingen meestal opslaan naar een UNC-pad. Voor samenwerking aan een document zijn echter meer functies nodig dan in de webclient-service beschikbaar zijn. Daarom is programmacode toegevoegd aan Office 2003 waarmee kan worden bepaald of een bestand door de webclient-service is geopend. Als een bestand door de webclient-service is geopend, wordt het pad in Office 2003 opnieuw toegewezen aan een volledige URL en wordt het bestand vervolgens apart geopend met het protocol dat bij het servertype hoort. Hierdoor kunnen in een Office 2003-toepassing alle functies voor samenwerking aan een document worden uitgevoerd, net alsof het bestand rechtstreeks vanaf de URL in Office is geopend. De informatie die eerder is geleverd, inclusief de informatie over Office-protocoldetectie, is van toepassing op documenten die worden geopend vanuit een UNC-share op een webclient.

Zonebeveiliging en beveiligingsprompts voor hyperlinks

In Office 2003 worden geavanceerde beveiligingsmaatregelen voor internethyperlinks in Office-documenten gebruikt. Hierbij hoort het doorsturen van beveiligingsreferenties onder een meer beperkend beleid voor beveiligingszones, waardoor in Internet Explorer het doorsturen van referenties naar de server kan worden toegestaan of geweigerd. Of het doorsturen wordt toegestaan of geweigerd, is afhankelijk van de zone-instellingen van de gebruiker.

Ook wordt in Office 2003 gecontroleerd of bij navigatie door de gebruiker WININET de juiste vensteringang heeft. Dit betekent dat WININET beveiligingsprompts voor de gebruiker kan genereren als de prompts voor de uitvoering van een taak vereist zijn. Hierdoor neemt de webbeveiliging in Office toe. Het is echter wel mogelijk dat door de grotere beperkingen voor Internet Explorer-beveiligingszones waarschuwingen worden gegenereerd die niet voorkwamen in eerdere versies van Office. De waarschuwingen worden weergegeven tijdens hyperlinknavigatie.

Ook wordt in de volgende situaties een extra waarschuwing in Office 2003 gegenereerd:

• Een gebruiker klikt op een hyperlink in een Office-document.
• Een document bevat inhoud afkomstig van een URL-bron waarin navigatie plaatsvindt.

De extra waarschuwing zorgt ervoor dat de gebruiker naar de website wil gaan en dat de site vertrouwd is. U kunt deze waarschuwing instellen in het register.


Klik op het volgende artikelnummer in de Microsoft Knowledge Base voor meer informatie: