Integrating with Microsoft .NET


Methodologies and Delivery Platforms

As with other code bases written in .NET, an integrated application can be tailored to run on any .NET support platform. The Microsoft .NET Framework is included with all major Microsoft operating systems, desktop and server, as well as Microsoft’s 3 major application platforms: SQL Server, Internet Information Services, and SharePoint Services. Thus, the API can be accessed and consumed across any of the aforementioned platforms with little to no additional development effort.

Generating and Consuming WSDLs: The Basics of Integration

In order for a .NET application to integrate with, a reference to the SOAP API must be added to the application within Visual Studio. This reference is established through the use of a WSDL file generated from the platform. A WSDL file is an XML file that describes how a SOAP-based web service functions, how an application can communicate with the web service, and the operations allowed to be conducted within the SOAP API.

In other words, the WSDL provides a description of the bridge between your Microsoft application, and a application running in a environment (or organization).

WSDL Types offers several types of WSDLs to consume, depending on the requirements of the application being developed and the audience for whom the application is developed. Regardless of the WSDL used, the API enforces several concepts across all WSDL types consistent with the World Wide Web Consortium’s (W3C) accepted standards including, but not limited to: how to communicate with the web service, how to authenticate with the web service, and what operations are allowed with the web service.

The platform offers many WSDL types for API access, with the primary WSDLs being the Enterprise, Partner and Apex Class WSDLs. Choosing the correct WSDL will depend on the type of application being developed.

  • Enterprise WSDL – This API is for users who are developing client applications for their organization. The enterprise WSDL file is a strongly typed representation of your organization’s data. It provides information about your schema, data types, and fields to your development environment, allowing for a tighter integration between it and the Web service. This is ideal if you’re writing an application for your own application and data. When using this type of WSDL you will need to re-import and compile your integration if you want your integration to be aware of data schema changes.
  • Partner WSDL – This API is for partners who are developing client applications for multiple organizations. As a loosely typed representation of the object model, the partner WSDL can be used to access data within any organization. This is ideal if you want to write something that will work against many different applications across many different partners without the need to be aware of the exact data schema implemented by the customer.
  • Apex WSDL – This API is used with custom Apex classes created on the platform. The API allows access to the properties and operations of an Apex class similar to objects exposed in the Partner and Enterprise APIs.

The important point here is if you want to create an application that can run against any customer application running on, then you probably want to use the Partner WSDL. For example, a generic data tool may have this requirement. However, if you have more control over the application you want to integrate with, and understand how often its data model changes, then the Enterprise WSDL may be more beneficial – the strongly typed representation is very useful during coding.

About the author

By juilee.joshi