Sep 10, 2010 at 1:21 PM
Edited Sep 10, 2010 at 1:24 PM
Based on your second message, I think you are starting to become more clear about how the batch commands work, but there still seems to be some misunderstanding -- both for the wrapper & the underlying MC batch api methods -- and for the rest of
the crowd who might be new to this, I'll explain a little more in depth.
First, as a reminder the wrapper just makes it easier to use the MC Api, the api still works as described in MailChimp's documentation -- and an understanding of how the api methods work is needed whether you use my wrapper, someone else's, or roll
your own api calls.
What my wrapper does as far as returning messages is embed two properties in the api_BaseOutput class -- api_ValidatorMessages and api_ErrorMessages.
The validator messages are only used if you set validation on, and are used to capture validation errors PRIOR to sending the api request to MC and they are not used to record any api call results.
The error messages class records two types of errors, api request results and program execution errors.
If the program execution fails, the error is captured via a try-catch block and recorded in the error messages, but the api call completes 'normally' rather than going 'yellow screen'. These errors have an 'ex' code and the error message is recorded.
If the api call is not valid (bad email address, missing data, etc.) -- as determined by MailChimp -- then error class contains the MC error code and description.
That all works fine when you are dealing with a single entity - be it a campaign, a list, or an individual subscriber -- but with the batch commands working against multiple subscribers, a means to indicate a problem against any single subscriber as well
as at the api call level is required -- so MC added an array of 'errors' in the returned fields with counts of good and bad.
So, by definition of how the MC api batch methods work, the api call will not have errors, but not all the data will be successfully applied -- and yes, for batch commands you need to verify both that the api call completed normally, and THEN determine if all
your data was successfully applied.
That said, cymen, the reason the api_ErrorMessages wasn't reset is that it is reset in the Output class constructor when you instantiate the 'command' class, not in the Execute() method, so you would have to put something like ...
listBatchSubscribe cmd = new listBatchSubscribe( input );
... before your ...
listBatchSubscribeOutput listBatchSubscribeOutput = listBatchSubscribe.Execute();
... to have it be reset.
I already have the change to move the Output class instantiation to the Execute() method, and some other related changes, on the project list for the next release.
I'll describe an approach that I would suggest as being more resilient for long-running batch api calls, in separate discussion topic, within the next few days.
Hope that helps,