Some more Feedback on FP1:

In order to implement discounts, we wrote our own discount management
tool instead of using the Discount Manager. Our own tool ties better
into our overall custom catalog management tool.

However, the new Microsoft Discount API is written such that you 1.
cannot activate/deactivate a discount using the Save method and 2. you
cannot save properties of a discount when a discount is "active".

This presents a problem for us because sometimes we may need to edit
discount properties (such as limits) on the fly, when a discount is
active.

The way I got around this is that when a discount is saved, it
deactivates the discount, saves the properties and then reactivates it
within the same method call.

There are 2 problems with this method

1. Performance - There are now 3 calls to the dbase, across the web
service 1. deactivate, 2. save properties, 3. re-activate. It isn't
that big of a performance hit but it seems inefficient

2. Same state errors - If a discount is already de-activated and you
call the deactivate method it throws an exception saying the discount
is already in the assigned state, instead of just leaving the discount
alone.

I think that if there is a custom API, it should basically let the
programmer do whatever they want to the discount, activate,
de-activate, save, update, whatever and trust that the programmer is
able to implement the correct safeguards on their own.

I understand the reason for these checks in the Discount Manager
application but maybe make the checks at the Application level instead
of at the API level.

Just some feedback on FP1.

Thanks!
Jason

[ Post a follow-up to this message ]

Jason,

see my reply in commerceserver.general group. Thanks again for your feedback
.

Andy Xu [MSFT]
Commerce Server Team
--
This posting is provided "AS IS" with no warranties, and confers no rights. Use of incl
uded script samples are subject to the terms specified at http://www.microsoft.com
/info/cpyright.htm

Note:  For the benefit of the community-at-large, all responses to this mess
age are best directed to the newsgroup/thread from which they originated.
--------------------
From: jasonsirota@gmail.com (Jason Sirota)
Newsgroups: microsoft.public.commerceserver.campaigns_csf,microsoft.public.c
ommerceserver.general
Subject: behavior of active/inactive status of discounts
Date: 28 Jun 2004 11:34:46 -0700
Organization: http://groups.google.com
Lines: 42
Message-ID: <12e66dac.0406281034.3a08f3e@posting.google.com>
NNTP-Posting-Host: 216.103.134.129
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1088447686 22689 127.0.0.1 (28 Jun 2004 18:34:46
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 28 Jun 2004 18:34:46 +0000 (UTC)
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA06.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSF
TNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!tiscali!newsfeed1.ip.t
iscali.net!proxad.net!
postnews2.google.com!not-for-mail
Xref: cpmsftngxa10.phx.gbl microsoft.public.commerceserver.general:14106 mic
rosoft.public.commerceserver.campaigns_csf:2747
X-Tomcat-NG: microsoft.public.commerceserver.campaigns_csf

Some more Feedback on FP1:

In order to implement discounts, we wrote our own discount management
tool instead of using the Discount Manager. Our own tool ties better
into our overall custom catalog management tool.

However, the new Microsoft Discount API is written such that you 1.
cannot activate/deactivate a discount using the Save method and 2. you
cannot save properties of a discount when a discount is "active".

This presents a problem for us because sometimes we may need to edit
discount properties (such as limits) on the fly, when a discount is
active.

The way I got around this is that when a discount is saved, it
deactivates the discount, saves the properties and then reactivates it
within the same method call.

There are 2 problems with this method

1. Performance - There are now 3 calls to the dbase, across the web
service 1. deactivate, 2. save properties, 3. re-activate. It isn't
that big of a performance hit but it seems inefficient

2. Same state errors - If a discount is already de-activated and you
call the deactivate method it throws an exception saying the discount
is already in the assigned state, instead of just leaving the discount
alone.

I think that if there is a custom API, it should basically let the
programmer do whatever they want to the discount, activate,
de-activate, save, update, whatever and trust that the programmer is
able to implement the correct safeguards on their own.

I understand the reason for these checks in the Discount Manager
application but maybe make the checks at the Application level instead
of at the API level.

Just some feedback on FP1.

Thanks!
Jason

[ Post a follow-up to this message ]