I have .net application which creating salesforce custom object dynamically but when i am using that object in my application it does not access it.
what i want to do is, i want to update the wsdl as soon as custom object created.
You are probably using the Enterprise WSDL, which contains stubs for all objects. If you expect objects to change (as you do here), then you should instead use the Partner WSDL. The Partner WSDL does not contain stubs for objects; instead, the partner WSDL file defines a single, generic object (sObject) that represents all of the objects.
For more information, check out the section called "Using the Partner WSDL" in the Salesforce.com API docs.
Related
I was able to download and include both the partner and enterprise WSDLs into my VS .NET 2010 project. In the Web References folder, all that appears is a Reference.map file, which, when I expand, exposes a few other .datasource files but no class stubs.
After including a reference to both APIs, I can not create an instance of my Salesforce classes (both native [such as Account] and custom). I need to do this for an upsert().
Is there something I am missing? Please help.
You don't typically need both the Partner and the Enterprise WSDL in the same project.
The Enterprise WSDL will be tailored to the schema of the generating Org and will have classes for Account, Contact etc and include properties for custom fields.
The Partner WSDL is designed to work with any Org, so it doesn't have specific classes. Instead you use a generic sObject and access XML Elements for the field values.
I'm trying to figure out how the WSCF Blue DataContract generation feature works.
It's documented here: http://alexmg.com/post/2009/09/01/Data-contract-generation-is-now-available-in-WSCFblue.aspx
I have a set of WSDL and XSD files from which we can use the "regular" method to create web service code.
The service generated does not allow you to use data contracts at the client end, meaning we get lots of Array types instead of List types.
Or more accurately, we can't get Lists, only Arrays so this means it's not using DataContracts.
So, when generating service code on the server side I get two options.
Use the regular option, generates an abstract class from which we create a concrete Service class
Use the "Generate Data Contract" option. This creates a .cs file containing just classes representing the the Xsd types, no abstract classes for the service.
So if I then try to generate the service classes with the regular options, I now have lots of duplicate classes representing the Xsd types.
I clearly have the wrong end of the stick.
Has anybody managed to make WSCF.blue work with DataContracts instead of the XmlSerializer?
We have several .Net webservices that we use a java client for. Each webservice has it's own namespace, but they all use a lot off common classes. When these are exposed as WSDLs, then generated into Java code, we get a lot of duplicates in Java of the same .Net classes.
Is there a way in .Net to define a set of WebService objects to be exported under a shared namespace (in XML)? Or can we when we use wsimport in Java to generate just one instance of each duplicate class?
From service side, one of the option could be to have specially crafted single WSDL describing all services. See this article for how to do it (applicable for asmx services).
On side note, for .NET clients, its quite simple to use wsdl tool with sharetypes options to have common types generated once and re-used among multiple service proxies. Hopefully, similar tools/options perhaps exist at java client side.
The -p option of wsimport allows you to override the namespace specified in the WSDL to a package that you specify. If you specify the same package for each WSDL you'll only end up with one instance of each class.
I'm currently trying to call a WCF service dynamically See here, therefore, I'm trying to understand what happens behind, when I add a service reference by the GUI of Visual Studio... What's generated..? An object is created and an implicit reference is created...
Are the references contained in a specific container, a sort of pool?
When you add a service reference, VS generates a proxy class for the service. This class implements the interface defined by your service endpoint as its ServiceContract, so it appears to consuming code as if it were the actual object performing the operations, but it contains and uses the communication channel defined by the endpoint and bindings to call the exposed service methods.
If you do not have classes that conform to the signatures of the DataContracts required by the service, VS will generate those classes as well, but if you have already referenced classes that are marked identically to the DataContract (usually because you've referenced the project containing the DataContracts in the project with the client-side code) it will simply use those. Svcutil (the command-line tool) can be given a reference list of locations for these DataContracts as well.
I have two "identical" webservices (Soap) on two different servers. Don't ask why :-)
WebService-1 decides if it handels the request itself or if it passes the request to WebService-2. If so, the response of WebService-2 should directly be returned from WebService-1.
The response datatype is complex and self defined. With simple datatypes like 'int or 'string' there would be no problem.
The response of WebService-2 is a serialized object (I think it is called "stubs") and theredore it is not possibel to pass this object through as the response of WebService-1 because the type of the objects doesn't match.
Is there a simple way to convert the serialised datatype into its original type without buiding a complex converter?
Yes - how to achieve this differs depending on whether you are using WCF or old-style Web Services.
Essentially, you want the web reference tools (svcutil.exe or wsdl.exe, respectively) to identify that the result of the webservice is actually a "well-known" object type - much as it does for many of the core framework objects.
Within WCF, this is normally achieved by ensuring that your contracts are held in a referenced assembly, and are decorated with namespace attributes. If you do this, when you add a reference to your webservice it should use your class natively instead of generating a similar proxy class.
If you are using old-style web-services, you will have to look into using a SchemaImporter project - this will allow the wsdl.exe tool to recognise your types and correctly utilise them. It should be mentioned that this is only required at design-time - no such measures are required during deployment.