Perfion is integrated with Sana, using the separately licensed Perfion-Sana Connector.

For a description of the functionality and installation/configuration manuals, please refer to the below and the Perfion knowledge base:

https://www.perfion.com/pim-features/sana-commerce-and-pim/

This document will focus on considerations concerning the realistically expected performance of the connector. It can be beneficial to read and discuss these considerations before initiating a connector implementation.

Performance Factors

The core functionality of the connector is essentially to enrich ERP data from Perfion before the result is sent to the Sana web shop:

Open

The details of this can be seen in the connector manual, but it is clear from the overview diagram that the response time of any update of products on the web shop will consist of these main components:

• ERP request response time

• Perfion request response time

• Connector processing and network transfer speed

• Sana product update based on connector result

The ERP request response time is out of scope of this document. If a slowly responding ERP system is the underlying cause of slow connector operation, the ERP partner can be engaged to discuss possibilities. In this situation, the situation would be the same even without Perfion and the connector.

With respect to the postprocessing by Sana, we refer to Sana’s own documentation about how this takes place. One known factor to consider is the presence of updates of many/large images, which can require substantial processing resources to take effect on the web shop.

Later section will discuss some general pitfalls relating to the way the connector handles changes to existing products.

Note that since the connector “only” enriches data returned from the ERP system, Sana will work the exact same way having the Perfion Connector or not.

Perfion Request Response Time

The request for data from Perfion will have a response time determined in essence by three factors:

• The amount of data

• The configuration complexity

• The hardware resources

Naturally, requesting 10.000 products will take longer than requesting 100 similar products.

And it is also natural, that if each product contains 3.000 features to be sent to Sana, then this will take longer than if e.g. only 30 features are used in the web shop.

Finally, the responsiveness of the SQL server is an underlying factor which will impact the response time (as well as the performance in general).

The Perfion Connector has been set up on numerous customers having hundreds of thousands of products, some with variants and having thousands of features mapped to Sana.

ERP systems are often slow to access, so Sana does two things:

1. Updates products incrementally, that is, only asks for updated products and only re-indexes them.

2. Asks for products in smaller chunks. That way ERP can answer requests in a timely manner. This, unfortunately is only the case when Sana does a “Full rebuild” (i.e. an indexing of all products) and not when doing an “Incremental update”.

3. Being nice to the ERP is also being nice to Perfion, since Perfion “only” needs to augment products coming from ERP.

Note that Sana has a default timeout of 120 seconds. This means, that does ERP together with Perfion spend more than 120 seconds answering any query, Sana will lose patience and the call will fail.

Connector Processing and Transfer

The connector itself is run from the same server which hosts Sana.

Since the majority of the time is spent on data retrieval and post-processing in Sana, then the connector itself will very rarely become a bottleneck. Should this happen, it will be easy to spot: If the total transaction time varies from ERP + Perfion response times, then connector resources could be a factor.

Delta Handling Pitfalls

When Sana requests for product updates, the first step is to ask ERP and Perfion for “which products have changed”. Then, for each changed product, the new data is requested from both ERP and Perfion. In all cases, no matter what part of the actual data has changed, everything (including images) is requested again.

This leaves open a potential performance impact, best explained with an example:

• Perfion has updated 10 products since last request

• ERP has updates, e.g. added a product feature for 10.000 products (which includes 5 of the 10 products above as well)

• The connector will do the math and hereby tell Sana that 10.005 products have been changed

• Sana requests all data and all images for all these 10.005 products.

A similar example could be that a mass-transaction has been performed in Perfion which corrects a spelling error on a T-shirt description text used on 100 T-shirts. If each T-shirt exists in 10 colors and 5 sizes, then this will mean that Sana requests all data and all images for each product (100 products, each with 50 variants). With 3 images pr. variant, this will mean a load of 100*10*5*3 = 15.000 images, which might not be obvious to the product manager who performs this operation in Perfion in a few seconds.

Sana and Perfion have devised workarounds for updating issues. These requires custom handling by Sana.