This document delineates the main system architecture of Perfion.

The intention is to give partners and customers an overall insight into the various components that can be combined in a running Perfion solution. The audience is mainly solution consultants or IT departments.

In general, Perfion is based on a Microsoft technology stack, and the guiding principle is to ensure flexibility and freedom for customers. This means flexibility in terms of buying and using few or many components, freedom to create custom integrations, and freedom of choice with respect to the underlying hosting solution.

The description is divided into the following chapters:

• Minimal Installation

• Web Client

• API and integration

• Application Server

• E-commerce connectors

• Asset Portal

• ERP integration

• Remote Data

• Other components

Each chapter builds upon the previous one, expanding on the same visual diagram. This does not mean, however, that each component is dependent on all previously described components. For more info about the dependencies, installation guidelines, and other details, please refer to the documentation for each component on the Perfion Knowledge Base.

Minimal installation

In its simplest form, Perfion can be reduced to a database server and a Windows application.

The simple diagram below is a fully valid deployment of Perfion and will provide all of the core PIM functionality needed to model, maintain and enrich product data:

Open

The database is installed on Microsoft SQL (or Azure SQL), and the Windows client is installed on the individual PC of each user. The Windows app is based on .Net 4.8 and will run in any modern Windows version.

In some cases, it can be a benefit to use Remote Desktop Services, Citrix or similar to expose the Windows Client for users. Some examples of use cases are:

• The user is already doing much of the daily work in a remote setup

• Non-Windows users who still prefer the full power of the app over the web client interface

• Scenarios where direct installation on user PC’s must be avoided

A new setup of Perfion in this way can be done in less than an hour, assuming the hardware is ready beforehand.

Web Client

Building upon the previous very simple deployment, it will in many cases be relevant to have users that access Perfion via the web client. In this scenario, we add one more component to the architecture:

Open

The web client is deployed as a service that can run on Internet Information Services (IIS) or in Azure as an App Service.

The technology used to develop the client (Angular/Typescript) ensures that it is compatible with any modern browser.

API and integration

More often than not, Perfion will need live integration to other systems.

For this purpose, our Perfion API provides a very flexible entry point, where “Perifon Query Language” (which is similar to SQL) gives a high level of control, going both ways.

This makes it possible to build customized applications that extend functionality or reuse information for any imaginable purpose, such as enhanced product information for your Web CMS or e-commerce.

Adding the API to our architecture, yields this new diagram:

Much like the web client, the API can be installed on IIS or as an Azure App Service. Often, the two will be installed alongside each other.

Some of Perfion’s partners have developed partner modules which provide additional functionality in a controlled and standardized fashion. These modules will always use the API for interaction with data.

The API has proven through more than decade that it is in fact possible to expand the functionality of Perfion without breaking the API interface, which means upgrades can be done without imposing additional cost to development of integrations.

The API provides both Soap/XML and JSON syntax.

Application Server

A more recent addition (2020) to the architecture is the Perfion Application Server (PAS).

The PAS is a backend service used to execute certain operations, decoupled from the end-user client. An example would be the generation of a large product catalogue via the reports/publishing functionality. Here, the web client will request the PAS to generate the report. The user can then continue to work before the result becomes available in an “inbox” in the client.

A second use case for the PAS is the scheduling of jobs/actions to be done one or more times. As an example, the PAS can be used to run a recurring nightly synchronization of data from an external source, or to do other data manipulations without user interaction.

This extra component fits into the architecture as shown here:

The PAS is a service running in Windows.

Notice that there is no direct communication between the web client and the PAS. Messages are passed via the database, which means that processing of messages/requests is performed asynchronously.

As pr. late 2020, only the web client makes use of the PAS to perform specific functionality. It is planned to allow the Windows client to also utilize the PAS in the upcoming 2021+ releases.

A Perfion installation with the components depicted above (database, client, API and server) is a very typical setup for a medium-complexity customer.

E-Commerce Connectors

With the Perfion API, it is possible to integrate any E-Commerce system with Perfion. However, for a number of specific E-Commerce systems, Perfion has developed dedicated connectors. The connectors are a standard product, ensuring a robust integration without custom coding from the partner or customer.

Currently supported (as of 2020) connectors are:

• Magento

• Sana

• Shopify

• Ucommerce

Since all E-Commerce connectors operate via the Perfion API, they can be configured and updated independently of the Perfion version itself. Although they each operate differently depending on the E-Commerce system, for reasons of simplicity we will add them to the system architecture as one box, as shown below:

The runtime technology for each connector is different, because of the way each E-Commerce system works. For example, the Sana Connector runs directly from within the Sana environment, whereas the Shopify Connector is a separate service which connects to API’s from both systems. See the separate documentation pr. connector for details.

Asset Portal

The Perfion Asset Portal is a separate component, which makes it easy to share media files with external partners (or the public, depending on settings). It is based on the API, but otherwise independent on other components in the architecture:

The Asset Portal is a Perfion “OEM adaptation” of a separate software suite, and is therefore based on another technology stack than the rest of Perfion. The Asset Portal requires a MySQL database and a PHP runtime environment.

Since the Asset Portal doesn’t depend on other components except for the API, it is completely valid to imagine another, simpler, deployment diagram:

ERP Integration

One of Perfion’s strengths is the tight integration to ERP systems.

We offer two additional components to support different use cases:

• ERP Add-in: Shows live Perfion data inside ERP

• Release2ERP: Moves data from Perfion into ERP

Adding them to our overall architectural diagram can be visualized like this:

The Add-in works differently, depending on the ERP system. For Microsoft Dynamics NAV and AX, the integration is based on the Windows client. For Dynamics 365 and SAP, the Add-in is based on the web client.

The Release2ERP module communicates via the Perfion API.

The current (2020) list of compatible ERP systems is shown below:

Remote Data

In the previous section it was stated that the Perfion-ERP integration has two components. There is in fact one more important use case, which is the ability to see or sync ERP directly inside ERP. This functionality is called “Remotes”.

Remotes can be used to fetch live data in grid views or the item editor, or they can be used to periodically sync actual data contents into the Perfion database. The supported data sources are:

• Direct SQL connection

• Web Service

• Odata

The remotes functionality is not a deployable component but is configured and shown via the client programs (or the API). However, we will still add this to the architectural diagram, to emphasize the importance of considering external data sources in a Perfion solution:

As mentioned before, using the remote data sources is not dependent on all the other components, so it is equally possible to use this concept in a more minimalistic deployment model. And of course, the Odata could for example be coming from the ERP system, but in our diagram above we show them as two different boxes, to keep it generic.

Other components and final thoughts

There are some additional components available when you run Perfion. However, in order to keep the architectural diagram from becoming too complex, and because of the “peripheral” nature of these components, we will only mention them in text form here:

Conclusion

This document has shown how Perfion solutions can vary from a very simple setup, and onto more complex scenarios with additional components and integrations.

There is no right or wrong deployment – each customer should use the components which provide value in their particular scenario. And as mentioned in the introduction, the hosting itself is selected by the customer (or Perfion can provide a SaaS setup).