System Requirements
- Windows 7 Enterprise
- Microsoft Office 2007
- Visual Studio 2010 Professional / Premium
- .NET / C# 4.0
Introduction
The invention of the service oriented architecture (SOA) offers the user the possibility to call web services and integrate these into new applications. SDN offers a special section for SOA, which can be accessed here.
I started a prototype project of integrating web services into an MS Office application (here it will be MS Word), based on the diploma thesis of Thomas Haas. Thomas integrated into a SAP Document Builder backend system, offering the possibility to call SAP Document Builder and to insert clauses from DocB into MS Word. However, one of the main challenges of Thomas' work was to determine WSDL and endpoint information of a given Web Service and to make the Web Service independent of the actual backend system - in other words how to determine the WSDL dynamically at runtime. This is where I started.
When starting with my prototype I came across numerous articles telling how to determine the WSDL manually if you know a services registry system. Examples:
- Anne Tarnoruder: "Introducing SAP Enterprise Services Explorer for Microsoft .NET"
- Igor Becker and John Miller: "How to call an SAP Enterprise Service from Microsoft Excel"
- "CE, ESR, AND DISCOVERY SYSTEM - BUILDING AN END-TO-END ENTERPRISE SOA SCENARIO"
However, all of these examples rely on the knowledge of a well defined backend at design time. My goal is to find out and describe an implementation which enables the end user (administrator) to choose a services registry backend at runtime.
For everything that I write below I assume that a running Services Registry is available. I will not elaborate how to install and set-up a Services Registry. My blog is based on the publicly available Services Registry http://sr.esworkplace.sap.com
Web Service to Read Services Registry Content
To my knowledge on the client (.NET) side of the web services infrastructure no API is available. On the other hand, the SAP Enterprise Service Explorer (see: The SAP Enterprise Services Explorer for Microsoft .NET: New interoperability offering for the Servi..., http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0319dc4-d76d-2a10-d19f-e4f4ff315...) offers exactly the type of interaction with a SR backend, which is required for my purposes.
Ultimately, the ES Explorer calls a web service in the Service Registry which returns information for a given web service. In our example SR (http://sr.esworkplace.sap.com) the WSDL to the service looks like:
- http://sr.esworkplace.sap.com/ServicesRegistrySiService/ServicesRegistrySiPort?wsdl
- User name = sruser
- Password = eswork123
In a "real" application, this static URL to the SR has to be made variable at runtime.
To start, you have to add a Web Reference to the Services Registry Web Service. To do so:
- In Visual Studio 2010, click on "Project" > "Add Service Reference"
- Enter the URL to your Services Registry and a name for the service:
After clicking the "Go" button, changed are made to your project:
- A new "Service References" entry is added to your project (Solution Explorer)
- XML code is added to you application configuration file (app.config)
Especially the second step causes a lot of trouble as this is exactly what we want to get rid of - a hardcoded URL to the services registry. It took me some research to find out how to fill the endpoint address to a web service dynamically at runtime and to get rid of the entries in app.config.
Calling Services Registry API Dynamically
The services registry can be called via the services registry API, which offers functionality to determine the parameters required to call other services published in the Services Registry.
Please continue and read the second part of this blog: "Prototype for MS-Office Add-In Integrating SAP Web-Services Part II - Working with the Services Regi..."
