Update: this service is not available anymore and has been phased out. If you need to use OPP use the available standard products like OPPS (cloud-based) or OPP XSA (official OPP software package).
Summary (tldr;): my team created a Docker-based OPP package which allows customers to create and deploy an OPP-standalone instance in ~30 minutes.
Omni Channel Promotion Pricing service is an optional add-on for CAR and can be used to integrate 3rd party software like web shops or cash systems so that these can benefit from correct pricing calculations based on promotions and rebates defined in SAP Promotion Management (which is running on top of CAR).
CAR is a centralized on-premise platform and serves as the foundation for multiple consuming applications and add-ons. OPP is such an add-on and it's provided as XSA deployment package via Support Portal to customers. When customers follow this approach they end up with a central instance of OPP on top of their CAR system.
A common issue customers have with this approach is that the central OPP instance is not guaranteed to be available at all times to all systems in their landscape. Especially components running at their Point of Sales might struggle with intermittent failures of network connectivity and cannot reach central services like OPP.
Customers are therefore heavily demanding a decentralized approach where OPP is running much closer to their Point of Sales so that the availability of the OPP service is strongly increased. Just imagine the situation where a person wants to pay his/her goods at the cash point and the cash till fails to process the purchase because it cannot reach the central OPP instance. But it needs to contact OPP for determining if there have to be certain rebates applied depending on what the person currently carries in the shopping basket. The very same situation might even occur for external web shops and of course other systems.
In 2018 there was a blog post which describes - on a very technical level - how customers can build their own custom version of an OPP instance for decentral deployments. This concept was called OPP Blackbox.However the blog post is very long and complicated and requires an appropriate (developer) skill set to understand the content and follow the concept. I recommend to have a quick look into the mentioned blog post to get an impression on how complicated it indeed is. By the way: the term "Blackbox" might be confusing and a better term would be "Standalone OPP". Anyway - most customers do not have the resources and capabilities to follow this concept on their own and would like to avoid spending time on such an implementation.
To overcome these issues my team invested into an easier solution for decentralized OPP deployments. Our goal is to get customers up and running as fast as possible and reduce the complexity by magnitudes. Our solution can be pictured like this:
Customers are left with a very few steps they need to perform on their side to deploy an OPP-standalone instance:
The overall effort is round about 30 minutes until the customer has a running OPP instance running locally. As a follow-up step the OPP Docker image can be exported and distributed to other hosts - no matter if private cloud or public cloud.
For a quick impression how that looks two screenshot of the 2 Docker images (opp-buildbox is the first image which builds the core OPP service aka PPS and opp-blackbox is the image running the OPP instance):
Important to be aware of is the fact that an OPP instance based on Docker will not cover the integration aspects with CAR and PMR. That means customers still have to configure DRFout and configure RFCs towards the OPP instance.
Last but not least: we provide the OPP Docker bundle not as final image but based on the source files for Docker and the integration layer. Customers therefore can modify the Docker build to their needs - at least with respect to the integration layer and which components are used in the later Docker image. That means if a customer would like to replace for example PostgreSQL with a different brand or the authentication mechanism for the HTTP-API should be replaced then they could do so on their own.
In case of questions about the OPP Docker build/image feel free to contact me directly.
Summary (tldr;): my team created a Docker-based OPP package which allows customers to create and deploy an OPP-standalone instance in ~30 minutes.
Omni Channel Promotion Pricing service is an optional add-on for CAR and can be used to integrate 3rd party software like web shops or cash systems so that these can benefit from correct pricing calculations based on promotions and rebates defined in SAP Promotion Management (which is running on top of CAR).
CAR is a centralized on-premise platform and serves as the foundation for multiple consuming applications and add-ons. OPP is such an add-on and it's provided as XSA deployment package via Support Portal to customers. When customers follow this approach they end up with a central instance of OPP on top of their CAR system.
A common issue customers have with this approach is that the central OPP instance is not guaranteed to be available at all times to all systems in their landscape. Especially components running at their Point of Sales might struggle with intermittent failures of network connectivity and cannot reach central services like OPP.
Customers are therefore heavily demanding a decentralized approach where OPP is running much closer to their Point of Sales so that the availability of the OPP service is strongly increased. Just imagine the situation where a person wants to pay his/her goods at the cash point and the cash till fails to process the purchase because it cannot reach the central OPP instance. But it needs to contact OPP for determining if there have to be certain rebates applied depending on what the person currently carries in the shopping basket. The very same situation might even occur for external web shops and of course other systems.
In 2018 there was a blog post which describes - on a very technical level - how customers can build their own custom version of an OPP instance for decentral deployments. This concept was called OPP Blackbox.However the blog post is very long and complicated and requires an appropriate (developer) skill set to understand the content and follow the concept. I recommend to have a quick look into the mentioned blog post to get an impression on how complicated it indeed is. By the way: the term "Blackbox" might be confusing and a better term would be "Standalone OPP". Anyway - most customers do not have the resources and capabilities to follow this concept on their own and would like to avoid spending time on such an implementation.
To overcome these issues my team invested into an easier solution for decentralized OPP deployments. Our goal is to get customers up and running as fast as possible and reduce the complexity by magnitudes. Our solution can be pictured like this:
- we use Docker as containerization technology which makes it easier to provide customers a prepackaged bundle
- the Docker build leverages OpenSUSE and PostgreSQL by default
- the Docker build makes use of the official release of OPP
- the Docker build contains an additional integration layer based on Spring Boot which connects OPP and PostgreSQL and activates the HTTP-API of OPP
- all above components are wired together already (e.g. database user is created automatically and referenced by the JDBC connection)
- the PostgreSQL database is mounted on a Docker volume (allows upgrading the container without loosing data)
Customers are left with a very few steps they need to perform on their side to deploy an OPP-standalone instance:
- downloading 2 OPP releases from the Support Launchpad (links provided in the bundle)
- installing Docker Desktop
- adjusting 4 parameters according to the customer setup in a single textfile
- execute 2 build scripts
The overall effort is round about 30 minutes until the customer has a running OPP instance running locally. As a follow-up step the OPP Docker image can be exported and distributed to other hosts - no matter if private cloud or public cloud.
For a quick impression how that looks two screenshot of the 2 Docker images (opp-buildbox is the first image which builds the core OPP service aka PPS and opp-blackbox is the image running the OPP instance):
The 2 docker images used for building and running OPP
Console output of opp-blackbox container
Important to be aware of is the fact that an OPP instance based on Docker will not cover the integration aspects with CAR and PMR. That means customers still have to configure DRFout and configure RFCs towards the OPP instance.
Last but not least: we provide the OPP Docker bundle not as final image but based on the source files for Docker and the integration layer. Customers therefore can modify the Docker build to their needs - at least with respect to the integration layer and which components are used in the later Docker image. That means if a customer would like to replace for example PostgreSQL with a different brand or the authentication mechanism for the HTTP-API should be replaced then they could do so on their own.
In case of questions about the OPP Docker build/image feel free to contact me directly.
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
