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,

first of all, thanks for your input. We really appreciate feedbacks from our
 develop community and I will forward your feedback to our internal team.

Here are my takes for the specific issues you mentioned.

We think directly modifying active discount can be dangerous. A typical scen
ario is with staging turning on, active discounts will be staged to producti
on sites every time staging job runs (every certain time
interval) and directly modifying active can cause careless changes affect th
e production data. That's the reason we provide a merchanism to save and app
rove -- two stage status before affecting production.

As of the exception when you deactivate the already inactive item, a best pr
actice, IMO, is to check the Discount.Active before calling the Deactivate m
ethod (only when Discount.Active returns true, you call it). The
exception is designed to tell you a status inconsistence from server. It is 
ususally useful in other cases. like, two clients concurrently deactive the 
same discount and the second caller should get the exception.

Let me know what you think. Believe me, we are serious about community feedb
acks and hopefully that can help us to deliver better product in the future.

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.general

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 ]

Yeah, I completely understand the reasoning for programming it this
way, it's definitely safer. IMO, I believe these safeguards that you
mention should be up to the programmer. But then again, I come from an
ASP Classic Background where EVERYTHING is left to the programmer.

As for checking the active status before calling activate/deactivate,
the concern I have is the number of calls to the database that I would
need in my situation. Take the following code for example (I apologize
for the VB):

--

Dim MarketingServiceUrl as String = "..." 'whatever
Dim MarketingSystem as New MarketingSystem(MarketingServiceUrl)
Dim Discount as Discount = MarketingSystem.GetDiscount(1) 'dbase call
1

If Discount.Active then
MarketingSystem.CampaignItems.Deactivate(1) 'dbase call 2
End If

Discount = MarketingSystem.GetDiscount(1) 'dbase call 3 - resets
Active flag

Discount.MaxAwards = 10
Discount.Save(True) 'dbase call 4

MarketingSystem.CampaignItems.Activate(1) 'dbase call 5

Discount = MarketingSystem.GetDiscount(1) 'dbase call 6 - resets
Active flag

--

If you could read/write the code into the database, without regard to
calling the Activate methods, this procedure would go from 6 database
calls above to 2, 1 to get the Discount from the dbase and 1 to save
it.

I also do realize that the Active property is read/write so after
calling the Activate/Deactivate method, I could set the Active flag
myself. And I suspect that's why you guys did it this way. But it
still seems strange to me that the Active property is read/write in
the object but you can't write it back to the dbase without an error.

Please let me know if there's a simpler way to do this..

Jason

[ Post a follow-up to this message ]