Develop > Presentation layer > Customize marketing
Promotion evaluation sequence development details
The promotions engine uses a construct called a Promotion Execution Agenda to effectively answer two questions:
- What promotions should be evaluated, and in what order?
- What policies govern each promotion identified in the first question?
The data in a Promotion Execution Agenda could be effectively represented as a table similar to the following example:
Promotions Policies Global Policies Group G1 Group G2 Policy 1 Policy 2 Policy 3 Policy 4 Policy 5 Policy 6 Policy 7 Group G1 Promotion A X X X X Promotion B X X X X Promotion C X X X X Promotion D X X X X Promotion E X X X X Group G2 Promotion F X X X X X Promotion G X X X X X
The table illustrates the promotions, and the policies that govern them. The table also displays how the promotions are grouped, and to which groups each policy applies. The promotion engine creates a Promotion Execution Agenda, based on information contained in the invocation template, which is specified in the call to the promotion engine. By default, an invocation template is a pre-configured list of promotion groups that will be evaluated during the call to the promotion engine.
The promotion engine is able to create groups that are both dynamic and transient, as required. These temporary groups are not persisted as the other groups are. The dynamic groups can be created based on both the static group information and other additional information available at the time a PromotionExecutionAgenda is created. The logic to create these dynamic groups is completely encapsulated in the buildAgenda method of the PromotionExecutionAgendaBuilder, which is a configurable component of the promotion engine. This flexibility provides us with the ability to adapt to situations like an extended site model where promotions can be created in a promotion collateral store and shared by retailer stores. In the diagram below, we have three stores. One collateral store and two retail stores. In this business model, both A and B shares the promotion collaterals created in Collateral store as indicated by the green dotted line. For each store, there are three different groups, static groups: Order Promotion, Product Promotion and Shipping Promotion. The business model determines that at store runtime for retail store A, promotions in the Order Promotion group of both the store itself and the collateral store should be evaluated as indicated by the white arrow in the diagram. Same type of arrangement for retail store B. This is not the same as in a B2C context where stores will share nothing between them.
To switch from a B2C to this model, all we need to do is to provide a new PromotionContextFactory with the buildAgenda method overwritten. This method will encapsulate the logic of merging the groups in both Collateral store and retail store when it builds the PromotionExecutionAgenda according to the business model and pass it on to promotion context objects being created by the PromotionContextFactory.
Promotion engine uses this sequence and PromotionExecutionAgenda to determine which promotion to evaluate next. Once the promotion is identified, all the constraints/conditions associated with this promotion is evaluated and rewards calculated if this promotion is applicable to the current order. Once the evaluation of a promotion finishes, one or more PromotionExecutionRecords are created (depends how many times this promotion can be applied to this order). The promotion engine will then try to determine if any promotion policies will be violated by adding these PromotionExecutionRecords to the existing mix (applying this promotion to the order on top of all the applied ones). If no policies violations are found, the PromotionExecutionRecord will be added to the result and the PromotionEngine will move onto the next promotion. This process goes on and on until all promotions in the sequence have been exhausted. Most of the methods on the PromotionContext class are defined to aid this process.
Related concepts
Related reference
Order Management subsystem URLs