- v1.0.0-latest-prod
| Name | Description | Default |
|---|---|---|
|
Audit verification properties provide a mechanism for controlling when the audit checks are performed. For more details, see |
By default, audit checks are disabled while running the applyOffer and marketing message endpoints but on during the endpoints that retrieve and validateOfferUsage endpoints. |
| Name | Description | Default |
|---|---|---|
|
TTL when caching offers by whether they should be applied automatically. |
5 minutes |
|
TTL for caching campaigns by their IDs. |
5 minutes |
|
TTL for caching offers by their IDs. |
5 minutes |
|
TTL for caching offers by their user target. |
5 minutes |
|
TTL for caching offers by their tracking IDs. |
5 minutes |
|
TTL for caching offer codes by their code strings. |
5 minutes |
|
Whether or not full offer code cache compilation should be performed. |
false |
|
Whether or not full code cache compilation should block the current request. |
Default is false, in which case the cache compilation occurs on a new thread. |
|
Whether or not full offer cache compilation should be performed. |
false |
|
Whether or not full offer cache compilation should block the current request. |
Default is false, in which case the cache compilation occurs on a new thread. |
|
The max number of offer codes to allow into memory when performing full cache load.
Requires |
20000 |
|
The max number of offers to allow into memory when performing full cache load.
Requires |
2000 |
|
The number of items to fetch in batch at a time. |
50 |
|
Amount of time between full offer cache compilation operations.
Usually smaller than |
4 minutes |
|
Amount of time between full offer code cache compilation operations.
Usually smaller than |
4 minutes |
|
Restrict full offer code caching based on activity status.
Possible values are |
ACTIVE_ONLY |
|
Amount of time in the past to include codes that were active.
Applies when |
30 days in minutes |
|
Amount of time in the future to include codes that will be active.
Applies when |
30 days in minutes |
|
Restrict full offer caching based on activity status.
Possible values are |
ACTIVE_ONLY |
|
Amount of time in the past to include offers that were active.
Applies when |
30 days in minutes |
|
Amount of time in the future to include offers that will be active.
Applies when |
30 days in minutes |
| Name | Description | Default |
|---|---|---|
|
Whether or not to enable the cache invalidation messaging flow in offer services. |
|
|
Amount of time to delay the sending of the offer cache invalidation message. |
|
|
Amount of time to delay the sending of the offer code cache invalidation message. |
|
|
See |
|
| Name | Description | Default |
|---|---|---|
|
Batch size for non-voucher campaign code generation. |
|
|
Batch size for campaign code generation for vouchers. |
|
| Name | Description | Default |
|---|---|---|
|
When recording OfferAuditDetails, whether to use customer’s email on the order as the |
|
|
When recording OfferAuditDetails, the system will record an overage of an offer used when this property is set to false. This is recommended for highest performance at the expense of potential small windows of offers being used above the max thresholds. |
|
| Name | Description | Default |
|---|---|---|
|
When rounding list of MonetaryAmounts, whether to distribute the rounded remainders across given MonetaryAmounts. For example, rounding 7 of $0.71428 with the total of $5 would result in 4 of $0.71 and 3 of $0.72.
If set to |
|
|
The RoundingMode to use for rounding order typed offer discounts |
|
|
Whether to round the offer discounts at the item unit level instead of the order level for order typed offers. For example, if we have an order with an item that is $99.99 and has a quantity of 3 with applied offer of 20% off order, then the 20% off discount would be rounded at the item unit level. That is, $99.99 x 20% = $19.998, after rounding it would be $20 discount per item unit, then $20 x quantity of 3, then the order’s total discount would be $60. Whereas if rounding is done at the order level, it’d be $99.99 x 3 x 20% = $59.994, and after rounding the order’s total discount would be $59.99. |
|
|
Whether to round order item typed offer discounts |
|
|
The RoundingMode to use for rounding order item typed offer discounts |
|
| Name | Description | Default |
|---|---|---|
|
Whether validations to ensure that |
|
| Name | Description | Default |
|---|---|---|
|
Whether or not to record every usage of offers in the audit details table. |
|
|
Whether or not fulfillment items will be included on the EnhancedOrder request into the offer engine. |
|
| Property | Description |
|---|---|
|
JPA Configuration Properties. See |
|
Datasource Configuration Properties. See |
|
Liquibase Configuration Properties. See |
|
Delegating Schema Configuration Properties for running in a composed mode along side other Broadleaf microservices. See |
| Property | Description |
|---|---|
|
Controls whether the Offer forms use Offer Template types to drive the UI with fewer individual flags to toggle rather than the previous, granular approach. Enabled by Default. This is only intended to be disabled to assist in migrating any Offer Metadata customizations and should be enabled as soon as possible for anyone upgrading to Offer Service 3.1.0. |