Enhancing Performance in large CCO Installations with SAP Business One as Backend

[R_Zieschang]

As the SAP Customer Checkout (CCO) community continues to grow, it's essential to address the performance challenges faced by partners and businesses utilizing SAP Business One as their ERP backend.

During the recent SAP SME Summit in Vienna in June 2023, several partners expressed concerns towards me regarding performance bottlenecks, primarily centered around the B1iF Server. Installations with 200 CCO instances and several millions of transactions per year.

Disclaimer: This blog wont talk about performance issues on CCO side but solely about the integration with B1.

To help overcome these challenges, we recommend implementing the following strategies as they are best-practices we adopted when we had larger CCO installations with B1 as backend.

1. Separate Concerns

To avoid resource contention and improve performance, it is advisable not to run the SAP Customer Checkout manager on the same Tomcat server as the B1iF server. By separating these components, you can ensure that each application has dedicated resources, leading to better overall performance. I will sketch out a "could be" architecture I set up on my MacBook and which performance gains I got.

2. Identify bottle necks

Identifying bottlenecks is a critical step in optimizing performance, even in distributed systems. While distributing workload across multiple virtual machines or servers can help alleviate some performance issues, it's important to consider the entire system architecture. A potential bottleneck could arise if all virtual machines are accessing the same slow Logical Unit Number (LUN) on the storage server.

In order to gain real performance improvements, it's crucial to visualize and analyze the architecture from a hardware, network, and application perspective. This involves assessing the capabilities of individual components such as storage servers, network infrastructure, and application servers, and ensuring they can handle the workload efficiently. By identifying potential bottlenecks in each layer and optimizing them accordingly, your system can achieve significant performance gains and deliver a smooth and responsive experience for your CCO installations and your customers respectively.

3. Scale Out the B1iF Server

To handle increasing workloads and prevent the B1iF Server from becoming a bottleneck, consider scaling out the B1iF infrastructure. Installing multiple B1iF servers and distributing CCO instances across them helps distribute the load and improves the responsiveness of your system. It's also useful to apply point one. Don't use the same database server for both B1iF Servers. (Mis)configured event-sender can also create a lot of IOPS on the database.

4. Adjust Master Data Sync Timing

By synchronizing the master data across CCO instances at different times, you can avoid a concurrent spike in requests that may overload the system. For example, you can schedule one store sync at minute 10, another at minute 20, and so on. This staggered approach prevents simultaneous data syncs and ensures a smoother operation. Also, I know it's tempting but keep in mind the impact of the check mark: Sync at startup. When all stores open at the same time, most likely all CCO instances will also sync all together.

5. Install Multiple SAP DI Proxies

Another recommendation to scale horizontally and improve performance is to install more than one SAP DI Proxy on the B1iF Servers. This configuration allows for better distribution of requests, reducing the chances of bottlenecks and enhancing the overall system's scalability.

5.1. Create DI Proxy Instances

First, create multiple instances of DI Proxies with help of chapter 5.1 of pdf document, attached to SAP Note 1993784.

5.2. Define Proxy Group

Then define DI Proxy group with help of chapter 5.2 of pdf document, attached to SAP Note 1993784

5.3. Assign the DI Proxy group to company databases

via Integration Framework → SLD for which you want to improve performance. See chapter 5.3 of pdf document, attached to SAP Note 1993784.

5.4 Assign sufficient memory to the DI Proxy

Please check SAP Note 2354463 for more details.

For other possible performance improvements, see SAP Notes 2245936, 2192737, 1873607

Implementing these recommendations can optimize the performance of your large CCO installations with SAP Business One as the backend. By separating concerns, scaling out the B1iF server, adjusting master data sync timing, and installing multiple SAP DI Proxies, you can mitigate performance bottlenecks and enhance overall system responsiveness.

Remember, the success of your CCO implementation depends not only on the software but also on strategic decisions and configuration choices. By leveraging these best practices, you can provide a seamless and efficient checkout experience for your customers while maximizing the benefits of SAP Business One as your backend.

6. My test architecture and performance tests

I set up 4 virtual machines.

• 1 SAP B1 Server (only repository + necessary stuff + B1 database) with 1 MSSQL Server running on Windows Server 2019


• 2 separate B1iF Servers with their own MSSQL Server with their B1iF DB deployed on it
  running on Windows Server 2019


• 1 CCOm running in Docker using MSSQL in a docker natively on my MacOS

(this architecture stresses my poor MAC a lot so I will only work with relatively performance gains 😉 ).

 

6.1 Performance tests

As I already mentioned running this architecture on natively on my laptop won't lead to representable numbers in terms of absolute numbers. But I was surprised to see performance gains. The first tests is assumed running at 100% performance. I used a small plugin which creates random receipts of differing sales item count, with customer, anonymous etc.
To achieve some delta syncs I randomly updated some item and business partner master data via a small script running against the service layer.

After every test I restored my B1 database, cleaned B1i log, restored monitor databases and also restored my CCO instances. Every test created 100 receipts. Every test was repeated 3 times.

Test was ended after all receipts were posted in B1.

6.1.1 First test - base test

First test running both CCO instances against the same B1i. Syncing master data on both CCOs at the same time. Syncing every 10 Minutes. All types of data at the same time.

100% time of base test

6.1.2 Second test - adjusting syncs

Same as the base test, but syncing was distributed on different timestamps per type (item + customer).

98% time of base test

6.1.3 Third test - using different B1iFs for each CCO

Same as second test but CCO_2 now uses the B1iF-02 as the integration server. Both B1iF server work with one DI Proxy.

90% time of base test

6.1.4 Fourth test - using different B1iFs

Same as third test but both B1iF servers have 2 DI Proxies running using 3 GB of memory.

82% time of base test

7. Summary and Conclusions

In summary, while the recommendations and the test cases presented here can be valuable starting points, it's crucial to approach performance optimization as a comprehensive and ongoing process. Measure your system performance. Create comparable performance tests and consult experts for every layer.

In my tests, I did not even change any configuration file of the B1iF tomcat etc. So you see there are ways to achieve performance gains, the architecture and configuration simply has to adapt to the expected workload.

In conclusion, as the CCO community continues to expand, it's crucial to address performance concerns head-on. By implementing the recommended strategies you can further scale and optimize the performance of your CCO installations.

Thanks for reading and please share all insights you may have gotten during your performance challenges and how you tackled them. 🙂

 

Robert

[JoergAldinger]

Thanks for this write-up, Robert.

Here I share a query that we use in systems with higher transaction counts, that shows the amount of pending transactions to be transmitted to B1 from the Monitor, organized by wait time (minutes in the queue).

This if course does not consider any transactions that have yet to be sent to the monitor, but it may be useful nonetheless for some basic monitoring. It could also be adapted to calculate the time it took from submission to completion, again, without considering time from CCO to Monitor.

SELECT

	"(m) in queue",

	SUM(CASE WHEN "ReleaseStatusCode" = 'NEW' THEN 1 ELSE 0 END) AS "NEW",

	SUM(CASE WHEN "ReleaseStatusCode" = 'REL' THEN 1 ELSE 0 END) AS "REL",

	SUM(CASE WHEN "ReleaseStatusCode" = 'INC' THEN 1 ELSE 0 END) AS "INC"

FROM

(

	SELECT

		"ReleaseStatusCode",

		CAST(ADD_SECONDS('1970-01-01 00:00:00', "BusinessTransactionDateTime" - 4 * 60 * 60) AS DATETIME) AS "DateTime_CCO",

		"CreationDateTime"-"BusinessTransactionDateTime" AS "(s) to B1i",

		CAST(ADD_SECONDS('1970-01-01 00:00:00', "CreationDateTime" - 4 * 60 * 60) AS DATETIME) AS "Fecha_B1i",

		"LastChangeDateTime"-"CreationDateTime" AS "(s) to B1",

		CAST(ADD_SECONDS('1970-01-01 00:00:00', "LastChangeDateTime" - 4 * 60 * 60) AS DATETIME) AS "Fecha_Act",

		FLOOR(SECONDS_BETWEEN(CAST(ADD_SECONDS('1970-01-01 00:00:00', "CreationDateTime" - 4 * 60 * 60) AS DATETIME), CURRENT_TIMESTAMP) / 60) AS "(m) in queue"

	FROM

		"CustomerCheckout"."PointOfSaleReceipt"

	WHERE

		"ReleaseStatusCode" <> 'CAN' AND

		"CreationDateTime" >= (SELECT MIN("CreationDateTime") FROM "CustomerCheckout"."PointOfSaleReceipt" WHERE "ReleaseStatusCode" = 'NEW')

)

GROUP BY

	"(m) in queue"

ORDER BY

	1 DESC

By the way, the "4" in "4 * 60 * 60" corresponds to our timezone adjustment, so you may have to adapt accordingly, our use a timezone conversion function instead.

Hope this helps a few people. Improvements are welcome.

Best regards,

Joerg.