I am trying to test my SF webservice api 7.0 calls that use soap compression using axis java 1.3. Can I use axis SOAPMonitor to sniff and pick up those http requests? My understanding is that SOAPMonitor has to be deployed on the web service side to monitor the soap traffic to/from that service - since in this case I do not have access to the salesforce webservice host, I presume I will not be able to use the SOAPmonitor here.

I tried tcpmon as well - it is able to intercept my request messages - I am not able to get the response back from the service. Not sure what is going wrong.

When I tried SOAP scope sniffer I get the following soap response:


ns1:UNKNOWN_EXCEPTION
UNKNOWN_EXCEPTION: content does not match Content-Encoding: gzip


UNKNOWN_EXCEPTION
content does not match Content-Encoding: gzip




Almost seems like soapscope sniffer is unzipping the messages before sending them on to salesforce - which should not be the case since I understand soapscope sniffer does not intercept and resend the message.

Any other way to verify soap compression?

How do we take care of a scenario where variations of the same product need to use the same product id but also need to have different list prices at the opportunity lineitem level. There is a list price at the opportunity level - but it seems to be read-only - any way to make that updateable from esp. from api?

What are the allowed/expected values for the content type field when creating an attachment using the API? Are they like "PDF", "TXT", etc, or is it more like "FILE", "NOTE", etc.

Using 6.0 API, I am trying to create lineitems for an opportunity that has a standard pricebook associated with it. Through API, I create a Product2 entry for that lineitem product (if required) and then create a PricebookEntry for that with following values:

Pricebook2Id = standard pricebook id (associated with that opp)
Product2Id = id of the Product2 entry created
unit price = specified by me
use standard price = true (as per documentation, this has to be set to true if the pricebook entry is for a std pricebook).

But the create call returns the error "Error 0: Message=No standard price defined for this product". I do not see any other way to define the standard price for that product. What could be the issue here? Or is it that the standard pricebook entries cannot be created through API?

Any suggestions about whether there exists transactional capability or how we can simulate it when we need an all or nothing behavior for a group of webservice calls?

Saw that the CommonsHTTPSender in the dataloader jar has the pkg common.api.soap. In the partner samples jar, it has the package org.apache.axis.client and the jar has .java files and the samples classes and other jars.

I need only this class (and the client-config.wsdd) for the soap compression and do not need the other dataloader or partner samples classes. What is the recommended way to use these 2 files in a packaged solution i.e. apart from including the whole dataloader/partnersamples jar?

I am using the 6.0 API and Axis Java. I have been told that if I try to save an opportunity product that does not exist in the opp price book - it will get entered in the pricebook on the fly. So I tried sending one opp lineitem with pricebookEntryId=null and productid=DynamicallyCreatedProduct (which does not exist currently in the pricebook) using binding.create(). But the api returned "Error 0: Message=ProductId: id value of incorrect type: DynamicallyCreatedProduct". Am I doing something wrong here?

In our application triggered thru' a custom link, we would like to validate the session id and user passed thru the link. What is the recommended way? I cannot find a way to validate (crosscheck) the userid with the sessionid.

After triggering an application using a custom link, is there anyway we can pass the return URL as one of the parameters through the custom link so that the application can return control to the same point within SF? From what I see, the current URL does not seem to be available as a field that can be sent through the custom link.

Using enterprise wsdl, I am getting the account and opportunity object xmls. The dates-times in those xmls show up as:


1118442218000


So is this the date or the date-time or only time. In either case, how can I convert it into a standard date-time format?

I am doing a query where I need the complete salesforce object (say account). It would be nice to have a * capability in the fieldlist. Currently I am doing a describe call and processing the fields returned into a comma separated list. Any other way I can have the * capability?

I am running a query with enterprise api as follows:
qr = binding.query("select id from "+objName+ " where Name = '"+objInstanceNameValue+"'");
objName=Account and objInstanceNameValue has an account value.

I am getting the error:

18312 [main] ERROR org.apache.axis.client.Call - Exception:
org.xml.sax.SAXException: Invalid element in com.sforce.soap.enterprise.sobject.SObject - type
at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:258)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1035)

What could be the problem?

While looking at the docs and samples, I saw references to the effect that the particular wsdl provided is for the developer edition. So is the wsdl, especially partner wsdl, edition sensitive? By its very purpose, I feel partner wsdl should not be edition sensitive, while enterprise wsdl maybe. In short, does it matter which SFDC edition I use for generating the wsdl?

We are integrating using weblinks, so username and session id (but not password) is passed through weblink. So we do not need to login using api - so their is no server url from the login result to update in the SoapBindingStub. Is that okay?

Also generally what is the concept behind this server url updation even in cases where you do login i.e. why can't we continue to use the general endpoint address that was used to setup the binding? Is it for reasons of load balancing on SFDC side)?


- Thanks.

Just wanted to point this out - the partnerSample.jar in PartnerSamples6_0.zip is packaged incorrectly. It uses the jar manifest to add jar files to the classpath which lie inside the partnerSample.jar itself. This is incorrect - as per Sun's JAR doc "The Class-Path header points to classes or JAR files on the local file system, not JAR files within the JAR file or classes on the network. To load classes in JAR files within a JAR file into the class path, you must write custom code to load those classes. For example, if MyJar.jar contains another JAR file called MyUtils.jar, you cannot use the Class-Path header in MyJar.jar's manifest to load classes in MyUtils.jar into the class path.".

I am trying to test my SF webservice api 7.0 calls that use soap compression using axis java 1.3. Can I use axis SOAPMonitor to sniff and pick up those http requests? My understanding is that SOAPMonitor has to be deployed on the web service side to monitor the soap traffic to/from that service - since in this case I do not have access to the salesforce webservice host, I presume I will not be able to use the SOAPmonitor here.

I tried tcpmon as well - it is able to intercept my request messages - I am not able to get the response back from the service. Not sure what is going wrong.

When I tried SOAP scope sniffer I get the following soap response:


ns1:UNKNOWN_EXCEPTION
UNKNOWN_EXCEPTION: content does not match Content-Encoding: gzip


UNKNOWN_EXCEPTION
content does not match Content-Encoding: gzip




Almost seems like soapscope sniffer is unzipping the messages before sending them on to salesforce - which should not be the case since I understand soapscope sniffer does not intercept and resend the message.

Any other way to verify soap compression?

How do we take care of a scenario where variations of the same product need to use the same product id but also need to have different list prices at the opportunity lineitem level. There is a list price at the opportunity level - but it seems to be read-only - any way to make that updateable from esp. from api?

Using 6.0 API, I am trying to create lineitems for an opportunity that has a standard pricebook associated with it. Through API, I create a Product2 entry for that lineitem product (if required) and then create a PricebookEntry for that with following values:

Pricebook2Id = standard pricebook id (associated with that opp)
Product2Id = id of the Product2 entry created
unit price = specified by me
use standard price = true (as per documentation, this has to be set to true if the pricebook entry is for a std pricebook).

But the create call returns the error "Error 0: Message=No standard price defined for this product". I do not see any other way to define the standard price for that product. What could be the issue here? Or is it that the standard pricebook entries cannot be created through API?

I am using the 6.0 API and Axis Java. I have been told that if I try to save an opportunity product that does not exist in the opp price book - it will get entered in the pricebook on the fly. So I tried sending one opp lineitem with pricebookEntryId=null and productid=DynamicallyCreatedProduct (which does not exist currently in the pricebook) using binding.create(). But the api returned "Error 0: Message=ProductId: id value of incorrect type: DynamicallyCreatedProduct". Am I doing something wrong here?

Using enterprise wsdl, I am getting the account and opportunity object xmls. The dates-times in those xmls show up as:


1118442218000


So is this the date or the date-time or only time. In either case, how can I convert it into a standard date-time format?

(Ok, the title could use work, but who am I, Steven King?)

In the process of preparing to migrate a bunch of integrations away from .NET (my client is going to be switching to Firefox with or shortly after the new release) I began work in earnest converting things to Java, and Axis. Most of the simple stuff came across fairly easily. Printing is another story entirely, but performance became an early problem.

Async calls in Axis seem to be _very_ undocumented. In fact I couldn't find any examples at all, and only a small directory of source code in the Axis source to guide me. After putting Async calls on the back burner I turned to SOAP compression. Before I get into my tale let me set some background. I hate modifying 'stock' code, and would much rather extend and override it where I can. The SFDC technote, while I'm soure it would work, did exactly this. (Seeing as I can't control _every_ machine that would get these applets deployed I can't depend on a modified Axis distribution.)

Off I went looking for solutions to the SOAP compression problem. Why neither .NET or Axis allow for (at least) receiving a gzip-encoded response is beyond me. Nonetheless Google is your friend and I quickly found this library for Axis SOAP compression... And there was much rejoicing.

That was until I actually tried it. Problem is that library makes a call to close the outbound socket. While normally not a problem, the Java SSL sockets really don't like this. In fact it pukes up a very nice exception for you. I even went as far as to disassemble the library and comment out those pieces of code. That didn't get far either as it appeared to just hang at that point waiting to read from the server.

From time to time you find a problem that just kicks your ass. The human spirit triumphs and you get determined to kick it's ass back into submission.

Two days later, holding my sorry and very disfigured ass after getting it handed to me, repeatedly, by SSL sockets in Java, I had pretty much rewritten the Axis HTTPSender routiene. I'd like to say it was all working quite well now, but I can't, in fact it had gotten about nowhere. Invariably what would work with SSL would fail without, or vice versa. Time to try another angle.

One of the stock Axis transports uses the Apache Commons HTTPClient library. Oh joy of joys, perhaps it knows how to do gzip encoding? Nope. Bzzt, sorry Hans, wrong answer...

But there just might be a way to do it. Another 8 hours later I find this interesting message howing how the HTTPClient PostMethod can be abstracted and overridden to allow for receipt of gzip encoded data. Not bad. Halfway there.

Copy and paste that into a class in Eclipse, and modify the one line in org.apache.axis.transport.CommonsHTTPSender.java, making it into my own class int he process, and vola it works!

The moral of the story: What a $%#@ PITA. And I still haven't even gotten to async calls yet...

If anyone is interested in my .java files I used to get here, or the ones that are FUBAR, let me know and I'll be happy to forward them over. My email address should be visible in my profile.

I'm going to wait a few days and give another crack at outbound compression and modifiying what I've got working so far... If anyone wants to chip in, let me know.