function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
apurswaniapurswani 

Mixing Enterprise WSDL & Apex WSDL

Hi,

We are using Enterprise WSDL to retrieve the records but it is not allowing me to maintain transactions so for create/update/insert we are using APEX class where we have maintained classes.

 

But now the problem is that :

it includes the entire Enterprise-WSDL like definition of all objects - including SObject, standard Salesforce objects (Account) and all our custom objects. In fact, we seem to have two definitions of Sobject - one from partner WSDL (com.sforce.soap.partner.sobject) and another one from Apex Class WSDL.

 

Can anyone tell me how to use it as it is showing "N" number of Compilte time errors while building application.

 

-Anil

 

AlwaysConfusedAlwaysConfused

I think you're confusing yourself here.

 

1. Enterprise WSDL is one version of the API that is "Enterprise specific" and defines each individual object (.eg. Account, Contact, ect)

2. Partner WSDL defines a "Generic implementation" that allows you to make calls against any Salesforce account / implementation.

3. APEX Classes define a "Custom Endpoint" within which you have acces to a proxied instance of the sObject definition on the server.

 

So you see you're actually dealing with 3 different API's (so to speak).

 

It sounds to me like your problem is overcomplication.

 

I think you would be best off choosing either the enterprise WSDL or the partner WSDL then build all your in house code against that.

On the server to do things that you can't do against the WSDL you can define custom fields that act as flags then set these and define "triggers" that will run APEX code on the server for you.

 

That way your solution becomes very simple ...

 

1. basic database operations like insert, update, delete, ect are handled by your in house code calling the WSDL endpoint.

2. Complex "processes / other" would be handled by the triggers executed upon success of the WSDL actions.

 

This allows you to separate your in house solution code from your Salesforce.com code and thus allows a more controlled layed approach.

 

If this is not a suitable solution to your problem I would love to know why, I am yet to find something that cont be done this way.

 

I have however chosen to take a more complex approach.

I built a sync process in SSIS that pulls updated records each day from salesforce down to a local db on an in house server, then I run my complicated stuff on the local db and push the changes to salesforce through the standard partner WSDL.

 

I can reuse this code on any SF account / implementation and the db need only reflect the object types I am interested in but also I can do anything with the local db and the sync process in SSIS worries about keeping SF up to date.

 

This means I can treat the SF endpoint as a simple slave to my process and don't have to complicate the SF platform with all my business processes with some complex language I prefer not to use (being a .Net developer en all).

 

In other words, I dictact the language I use, the processes, and keep SF to being as simple as possible.

 

I then also get the added benefit of being able to run complex analytical work on the SQL db (e.g. try building a report in SF that  takes in to account totals from campaigns, campaign members, contacts and accounts), yes this could be done in apex, but it's easier to do with a small amount of SQL ;)

AlwaysConfusedAlwaysConfused

 

It might be worth adding that you should have 3 sets of binding configuration, maybe the compile time errors are related to binding?

 

Also,

 

Instead of using ...

 

sObject obj = new sObject();

 

... try using ...

 

sObject obj = new com.sforce.soap.sobject();

 

... this is what we call the "fully qualified name" of the object, maybe by doing this you refer more specifically to that particular definition  of the sObject type.

 

Just remember that you can't pass 1 definition of the object to a method that expects another definition of the object as these are technically totally different types that derive from totally different base types.

 

This may explain type conversion errors at compile time and run time.

apurswaniapurswani

Thanks for everyone's suggestion....

 

but I tried it in a little different way.... as I seen that it is creating duplicate definition for standard / custom objects so I created a new project and added APEX WSDL there. thereafter I created dll file and referred it in a project where I am using SalesforceStandardAPI.

 

As now while creating instance I had to take care of namespaces too.

 

like instead of directly creating object of any standard/custom objects like:-

 

Account a = new Account

 

instead of above code I used following:-

 

StandardAPI.Account a =new StandardAPI.Account();

 

And for APEX Generated code I had used following:-

 

APEXAPI.Account aa = new APEXAPI.Account();

 

 

NOTE: StandardAPI and APEXAPI are the namespace which I had given at the time of generating cs file using wsdl tool

 

for e.g.

wsdl /l:cs /out:apexapi.cs /namespace:APEXAPI "apexapi.wsdl"

 

and

wsdl /l:cs /out:StarndardAPI.cs /namespace:StandardAPI "standardapi.wsdl"

 

in above example "apexapi.wsdl" and "standardapi.wsdl" are the names of file which I had saved in my desk.

 

 

 

-Anil