Leonid -
First - sorry to all for the top post.
Second, thanks Leonid for the prompt and insightful reply. As one of the
6000 resellers who has long been vocal about the fact that some resellers
require language-independence in both the RCL and the RWI, I understand your
point.
You mentioned that the client code implementation handles error code 7502...
I looked up how our implementation of the RCL code (based initially on
version 2.60 and later the 2.61 update) handled the response, and saw no
special handling of this code. Downloaded subsequent versions of the RCL
client code and finally see this response makes its appearance in v 2.75
released this spring (mid April?)...
The post here could not be more right on:
http://www.opensrs.org/archives/discuss-list/0310/0129.html
Once you have spent the time integrating an RCL release into your payment
gateway, templates, database, etc., unless you have very high volume or a
lot of time on your hands it is not realistic to try to keep up with the
latest version of the "RCL" client. I'll bet there are a large number of
resellers out there using the pre-XML client 2.01 or whatever it was. The
longer you have been using this system the harder it is to keep updating
it...
So yep, you are right. There is indeed an error code 7502 as of April in
the RCL which can now be used to handle this type of situation. Now I just
have to figure out if it is easier to "back-port" this into our customized
client, or update the client into the latest version.
Personally, I think this is truly an issue with respect to the client code.
The "OpenSRS-SF client status" thread raises some important issues...
--
John Keegan
[EMAIL PROTECTED]
http://RackShare.com
> From: Leonid Igolnik <[EMAIL PROTECTED]>
> Date: Tue, 7 Oct 2003 22:52:20 -0400 (EDT)
> To: John Keegan <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: certs, horizon and low balances
>
> John,
>
> Let me take a step back here and try to explain a general
> reasoning of why API's for the different products behave differently. We
> as a wholesaler serve a channel of about 6000 resellers, each with there
> unique business processes requirements and frontend languages. Our
> customers need to be able to integrate our API's into their system and be
> able to follow their own business processes based on what happens to their
> requests sent to OpenSRS system. They also should be able to generate an
> end-user message using a language of their preference. We also see a need
> to simplify reseller's life by providing him/her with an accurate error
> message (you'll be surprised how many reseller are looking for there
> processed order just to find out it was pended).
> To support this the newer APIs return an accurate message that
> will allow the reseller to see why the request to the system failed, with
> that error message we will also return an error code specific to the
> failure so the reseller is able to take appropriate action (IMHO doing
> this based on the error code is simpler than parsing our messages which
> are not guaranteed to remain the same). Our client code implementation
> includes basic error code/message conversion along with specific handling
> for the code 7502 - which is the code indicated that reseller did not
> have enough funds to process the order.
>
>> Not sure if this is consistent with behavior of other OpenSRS products or
>> even logical. Domains don't return an error code if there is an insufficient
>> balance.
> I agree it is not 100% consistent, but we have to start the process of
> improving our API's somewhere. New protocol seemed like a logical choice.
>
>> That makes sense - the error is either confusing to the customer ("Failed to
>> create order: Insufficient balance - the customer might think you are
>> talking about their balance) or embarrassing to the reseller (Customer would
>> think you don't pay your bills or something).
> I agree, it does not make any sense if you assume that the error is for
> the end user. But the error is there for you along with the code.
>
>
> I would be interested to hear the feedback from the other members of this
> list on this issue.
>
>
> Leonid Igolnik
> OpenSRS developer.
>
