5

We currently have couple of call ins where an external application has to call apex webservices to perform data operations. We anticipate multiple webservices to be exposed in apex and we want to perform lesser maintenance on the wsdls for the client to maintain. So we are thinking if we can just provide the enterprise wsdl which can encapsulate all the custom wsdls. Is this possible or if not what are the options to minimize number of wsdls exposed to other clients to call salesforce?

1
  • 1
    I'm not sure I follow. I've never heard of your custom Apex webservice WSDLs being combined into the Enterprise WSDL. I suspect what you want is the Partner WSDL. It doesn't need to be refreshed unless you need access to features in a new Salesforce release. Oct 18, 2013 at 0:57

2 Answers 2

6

Unfortunately the Enterprise WSDL does not aggregate Apex Web Services defined in the org, only custom objects. I've also confirmed this by writing a short Apex Web Service, downloaded the Enterprise WSDL and searched it for my class and it is not present.

Force.com Enterprise WSDL—This API is for most enterprise 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 Force.com Web service. This WSDL changes if custom fields or custom objects are added to, renamed, or removed from, your organization’s Salesforce configuration. If you are downloading an enterprise WSDL and you have managed packages installed in your organization, you need to take an extra step to select the version of each installed package to include in the generated WSDL.

If you have many Apex classes wishing to expose web services, i agree it can be quite cumbersome to manage the multiple WSDL's and not possible to share common types across the resulting WSDL's.

The suggestion I can offer, in order to maintain the code in separate classes is to perform the aggregation via a single Apex Webservice class that purely acts as an endpoint and thus WSDL for Apex Web Services. It contains no code other than to delegate to the others classes you have already. I would consider some kind of naming convention on the methods to help group the operations.

global with sharing class MyUberService
{
    global class SharedType
    {
        webservice String someMember;
    }

    webservice static void ServiceA_SomeMethod(String parameterA, SharedType sharedInfo)
    {
        ServiceA.SomeMethod(parameterA, sharedInfo);
    }

    webservice static void ServiceA_AnotherMethod(Decimal parameterA)
    {
        ServiceA.AnotherMethod(parameterA);
    }

    webservice static String ServiceB_DoSomething(SharedType sharedInfo)
    {
        return ServiceB.DoingSomething(sharedInfo);
    }
}

As you can see this would also help you share types between services and thus the generated C# or Java code once the WSDL is consumed by your client.

Thoughts on REST. Regarding REST, I'm a big fan of the simplicity of API's utilising this form of web service convention. Web Service standards have grown very bloated and hard to use without the help of a framework, so REST definitely addresses this, especially for mobile framework clients this is important. However when the client environment allows it, I am also a big fan of strongly typed interactions with API's. So if you have a lot of complex data structures and many operations, sometimes SOAP and WSDL's offers a lower barrier to entry to your callers as they get a locally generated API in their native language to consume as apposed to having to construct JSON structures at runtime. Big fan of both for different reasons! :-)

4
  • REST is superior to SOAP in almost every way possible, so I'd definitely recommend this approach when practical. BTW, there's nothing stopping you from using REST in WSDL. You can have your cake and eat it, too.
    – sfdcfox
    Oct 18, 2013 at 14:08
  • And then of course there is WADL (REST version of WSDL)! A WADL to Apex generator would be great! I don't know of many REST services described via WSDL though. Oct 18, 2013 at 14:29
  • 1
    I'm thinking about writing one... I've never thought of it before, but it makes perfect sense. It could be in Apex Code without too much difficulty with the Tooling API, although I might instead make it a Visualforce page for ease of use.
    – sfdcfox
    Oct 18, 2013 at 14:33
  • That would be great, check out the ApiGee console and the WADL they put together for Salesforce. With a WADL they generate a Web Console for testing REST, very cool! Oct 18, 2013 at 15:19
1

As I understand it, when you create an Apex webservice, those methods are added to your enterprise wsdl.

That said, I suggest looking at Rest services.

1
  • @Andrew Fawcett, Thanks for your answer. I like the delegator pattern of the webservice which you are suggesting which would cut down the number of wsdls on our end. Thanks for your detailed answer. Oct 18, 2013 at 14:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .