3

I'm wondering if there is a way for me to get a .Net - made web service into a state that Salesforce can recognize? What I have to work with is a service that is made with Visual Studio and comes with the .svc ending, but as far as i can see it conforms to the SOAP standard. But when I try to import it into my sandbox for testing i get the error that this WebService is referring to an external XSD source for the XML layout and Salesforce can't deal with that. I'm not entirely sure what I can do to rectify this. Can I use some flatting technology to embed the XSD into the svc file and then import it? I have no control over this external service since it's a third party, and also authenticated.

This webservice would be called with an outbound message via a workflow on a custom object.

Are my options these?

  1. Make a seperate class that handles the logic for calling this external endpoint, including the login/auth process
  2. Create an Apex class that the workflow does a callout to, and the only thing that class handles is a callout to real logic code that would be the service above. I don't see how else I can do since I need to authenticate to the external service also.
Improve this question
3
  • When you say it conforms to the SOAP API, are you referring to the Salesforce SOAP API for use with Apex? I strongly suspect the answer to your question is that you'll need to create your own webservice exactly as you've outlined in your post. Examples of that abound in books and blogs around the web.
    – crmprogdev
    Apr 27, 2013 at 14:57
  • My thought was at first: How can I generate Apex classes from this webservice if it's referencing outside XSD schema endpoints? Is there any workaround for that? If I could get this into Apex code that would help alot, otherwise I'll just have roll my own.
    – akarnid
    Apr 27, 2013 at 21:51
  • I've put some guidelines into an answer for you. However if you want to provide the WSDL to the service your trying to consume via a Gist link (gist.github.com) or something I can try to help further. Note to obtain the WSDL from a .Net svc definition add ?wsdl to the end of the URL.
    – Andrew Fawcett
    Apr 28, 2013 at 9:38

1 Answer 1

Reset to default
2

Your question seems to reference two ways of consuming Web Services, both are independent of each other. Outbound Workflow actions have very specific requirements that this service will likely not meet if its been designed independently. So using Outbound Workflow may not be possible, unless you go back to the service provider to change. Otherwise you can choose to attempt to consume the Web Service directly via Apex and Apex Triggers, this approach does not utilise Salesforce Workflow, as it cannot call Apex.

Here is a summary of both just in case.

Outbound Workflow messages must conform to a predefined (by Salesforce) definition. You cannot have such Workflow actions confirm arbitrary Web Services unfortunately. This help topic describes how to obtain the WSDL (Web Service Definition Langauge file). You then need to give that to your service provider or build the web service yourself. For example .Net's VisualStudio will consume the WSDL and generate some stub code to enable you to complete the implementation of the web service.

Consuming the WSDL and calling via Apex. There are a few approaches to getting the best out of the WSDL2Apex tool (accessed under Develop > Apex Classes > Generate from WSDL) to generate your Apex code. It has some feature gaps but also some reasonable workarounds as well.

  1. Review the 'Apex Callouts' section of this article and the formal docs here.
  2. Review and pay close attention to the supported features here, it's not neccessarly a stopper, depending on the unsupported feature you need. Since you can edit either the WSDL file and/or the Apex generated code to workaround some. Which is sometimes not ideal, if your WSDL is changing often. However maybe prefferable to manually constructing the SOAP messages as per the last option below, which is more fragile and involving.
  3. Review and pay close attention to the understanding of the generated Apex code here.

  4. Run the WSDL2Apex tool and editing the WSDL.

    4.1 If you get errors such as XML Schema must be embedded. Download the WSDL (add ?wsdl to the end of a .Net svc URL) and attempt to edit locally before giving it back to the WSDL2Apex tool.

    4.2. Often you can edit the WSDL without breaking the contract (structure of the XML packets) it describes. Such as copying (or flattening) in the XSD xsd:schema root tag into the WSDL file body using the wsdl:types element. As shown in the W3C standards doc here.

    4.3. Some unsupported data types can be changed to xsd:string. You must then ensure that your Apex code populating the generated member variables of the classes formats things according to the expected data type.

  5. Once you get the Apex code generated, you may find it still does not work, for example if xsd:extension is used in the schema. However you can modify the generated Apex code to resolve this. The notes here describe how this has been done for the Salesforce Metadata API, but the same approach applies.
  6. Finally, if you cannot get the WSDL2Apex tool approach to work, but you can get hold of sample of the SOAP XML being transmitted to the service. You can manually make the Web Service call out using the the XML and HTTP features of Apex. As described here.
Improve this answer
1
  • Your very welcome, let me know how you get on!
    – Andrew Fawcett
    Apr 30, 2013 at 12:14

You must log in to answer this question.

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