Stratégies de promotion personnalisées
Le moteur de promotion est configuré avec un ensemble de stratégies de promotion par défaut appliquant les règles relatives, par exemple, à l'exclusivité d'une promotion, à la combinaison de promotions ou aux limites d'utilisation. Si l'ensemble de stratégies de promotion par défaut ne répond pas à vos besoins métier, vous pouvez implémenter des stratégies de promotion personnalisées.
L'ensemble de stratégies défaut est répertorié dans Organisation des promotions. L'introduction de stratégies de promotion personnalisées est un travail en deux phases. La phase 1 implémente de nouvelles stratégies. La phase 2 affecte la stratégie à l'un de vos groupes de promotions ou la marquage comme stratégie globale. Pour affecter une stratégie à un groupe, voir Personnalisation de l'organisation des promotions. Si vous créez une stratégie et que vous la marquez comme active sans l'affecter à un groupe, elle est considérée comme globale.
Toutes les stratégies personnalisées doivent implémenter l'interface com.ibm.commerce.marketing.promotion.policy.PromotionPolicy. Cette interface est une sous-classe de XMLizable, ce qui signifie que vous devez implémenter les méthodes toXML et fromXML, et concevoir un formulaire XML sérialisé pour votre stratégie.
La méthode clé d'une stratégie de promotion est la méthode apply. Elle admet deux paramètres : PromotionContext et PromotionExecutionRecord. Une stratégie de promotion est appelée lorsque les conditions d'une promotion sont remplies et que les ajustements de la promotion ont été "provisoirement" appliqués au contexte de promotion. La responsabilité d'une stratégie de promotion, remplie par la méthode apply, consiste à vérifier l'état du contexte de promotion pour déterminer la présence de violations. Une stratégie de promotion doit lire le contexte de promotion afin de déterminer l'impact de l'application de la promotion à la commande. Les informations détaillées sur le contexte de promotion sont disponibles dans la documentation d'API. En particulier, notez les méthodes qui gèrent le contenu non validé dans le contexte de promotion. La méthode apply doit renvoyer une valeur booléenne indiquant si une violation est détectée (true) ou non (false).
Le code ci-après est un exemple de stratégie.
package com.ibm.commerce.marketing.promotion.policy;
import com.ibm.commerce.marketing.promotion.reward.MonetaryAdjustment;
import com.ibm.commerce.marketing.promotion.runtime.PromotionContext;
import com.ibm.commerce.marketing.promotion.runtime.PromotionExecutionRecord;
/**
* Checks whether applying a promotion drops the order running total to zero or not.
*/
public class NoneZeroOrderTotalPolicy extends PromotionPolicyBase {
/**
* IBM copyright notice field.
*/
public static final String COPYRIGHT =
com.ibm.commerce.copyright.IBMCopyright.SHORT_COPYRIGHT;
/**
* Constructor.
*
*/
public NoneZeroOrderTotalPolicy(){
super();
}
/**
* This method checks if the order total will drop to zero or not
* after a promotion is applied.
* @return true if the order total remains positive,
* false if the order total is zero or negative.
* @see com.ibm.commerce.marketing.promotion.policy.
* PromotionPolicy#apply(
* com.ibm.commerce.marketing.promotion.runtime.PromotionContext
* com.ibm.commerce.marketing.promotion.runtime.PromotionExecutionRecord)
*/
public boolean apply(
PromotionContext context,
PromotionExecutionRecord record)
throws PromotionPolicyApplicationException{
return (
context.getOrderRunningTotal(MonetaryAdjustment.PRICE).signum()>0);
}
}
Notez que la classe PromotionPolicyBase fournit les méthodes toXML et fromXML de base pour les stratégies de promotion qui n'ont pas de formulaire XML sérialisé hormis le formulaire simple illustré ci-dessous :
<PromotionPolicy impl="fully qualified implementation class name">
<PromotionPolicyKey>
<PolicyName>Unique Name for the policy</PolicyName>
<StoreKey>
<DN>o=root organization<DN>
<Identifier>BlueStore 202</Identifier>
</StoreKey>
</PromotionPolicyKey>
<Status>Active</Status>
</PromotionPolicy>