Re: HTTPAPI Batch Jobs

[Andy Buchholtz <andy@xxxxxxxxxxxxxxxxxx>]

Thanks to everyone for all the help.

Scott you are correct in that a SOAP fault tag is not found in the xml  
being parsed out by the XML parser. I am trapping errors based on the  
information returned from the XML parser not based on the debug log.  
When I trap the errors I consider anything where rc <> 1 to be an  
error and write it to a log. I changed the program to write the  
http_error to the file if my return code (fault string in my case) is  
blank, the http error that is being generated is SendRaw(): callback  
returned an error. This is pretty generic message so I pulled one of  
the files from the ifs that generated this error and manually sent the  
file to Salesforce, it successfully transmitted. My next step is to  
run the same file on the iseries to see if it will process or if I get  
the same http_error. I may try and increase the time out parm to see  
if the error is related to not getting a response back from the SOAP  
server in the expected time frame.

On Oct 6, 2009, at 9:48 PM, Scott Klement wrote:

> Hi Andy,
>
>> First off I want to thank Scott for providing this forum and . . .
>
> I'm glad you're finding it useful.
>
>
>> The issue that I have found or I am running into is when the batch
>> job runs in a single threaded jobq I can see that all the return
>> fault string returned from the API, but when I change the job to run
>> in a multi threaded jobq (10 active jobs) I get several error
>> records that do not have a fault string associated with them.
>
> I'm not sure that I follow this.  What is meant by 'several error
> records that do not have a fault string'? You mean that the SOAP  
> 'fault'
> tag isn't found in the XML that's parsed by the XML parser in HTTPAPI?
>
> Or are you referring to messages not being found in the debug log?
>
> Your question would make sense if you are using the same debug log for
> multiple jobs running at the same time, because the default filename  
> for
> the debug log doesn't change from job to job.  If you have multiple
> jobs, they'll all be writing to the same IFS filename at the same  
> time.  .
> ..But only if you are getting the soap fault info from the debug log!!
> Which isn't something I'd recommend. The debug log is for debugging,  
> not
> production use.   If you are getting a 'fault' element from your SOAP
> message, your production code should be receiving this via the XML
> parser and loading it into variables accordingly.  Not scanning for it
> in the debug log!
>
> HAving said that... if that is the problem, you could solve it by
> assigning a different debug log filename to each batch job.  (Perhaps
> use the same date/time you put on the input filename)
>
> myLogname = '/tmp/httpapi_debug.txt-' + %char(myTimestamp);
> HTTP_debug(*ON: myLogname);
>
> So it's possible -- I just don't recommend it :)  it seems sloppy to  
> me.
>
> On the other hand...
> If the problem is that the XML parser isn't successfully returning the
> fault message, then I'm at a loss.  I can't see why it would matter at
> all how many jobs are running in the job queue in this case, because  
> in
> this case they aren't sharing the same files/resources.  So how can  
> they
> conflict?  If that's the case, more investigating will be necessary...
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------