• Minimal installation
• Web Client
• API and integration
• Application Server
• E-Commerce Connectors
• Asset Portal
• ERP Integration
• Remote Data
• Other components and final thoughts
  • Conclusion

 

This document outlines the core system architecture of Perfion.

Its primary purpose is to provide partners and customers with a comprehensive understanding of the different components that can be combined to create a functional Perfion solution. The target audience includes solution consultants and IT departments.

Perfion is built on a Microsoft technology stack, with a focus on ensuring flexibility and freedom for its users. This flexibility allows customers to choose from a range of components, create custom integrations, and decide on the underlying hosting solution that best suits their needs.

The document is organized 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, elaborating on the same visual diagram. However, this does not imply that each component relies on all the previously described components. For further information regarding dependencies, installation guidelines, and additional details, please refer to the documentation for each individual component in the Perfion Knowledge Base.

Minimal installation

In its most basic configuration, Perfion can be simplified to a database server and a Windows application.

The simple diagram below illustrates a fully valid deployment of Perfion, offering all the core Product Information Management (PIM) functionalities necessary for modeling, maintaining, and enriching product data:
 

The database is installed on Microsoft SQL (or Azure SQL), and the Windows client is deployed on each individual user’s PC. The Windows app, built on .Net 4.8 is compatible with all modern Windows versions.

In certain scenarios, it may be beneficial to use Remote Desktop Services (RDS), Citrix, or similar solutions to provide the Windows Client to users. Some common use cases for this approach include:

• The user is already working primarily in a remote setup
• Non-Windows users who still prefer the full power of the app over the web client interface
• Scenarios where installing the application directly on user PCs must be avoided

Setting up Perfion in this manner can typically be completed in under an hour, provided that the necessary hardware is prepared in advance.ehand.

Web Client

Building upon the previous simple deployment, it is often relevant to include users who access Perfion via the web client. In this scenario, we introduce an additional component to the architecture:

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

Developed using Angular and Typescript, the web client is designed to be fully compatible with any modern browser.

API and integration

More often than not, Perfion requires live integration with other systems.

For this purpose, the Perfion API provides a highly flexible entry point. With the Perfion Query Language (similar to SQL), users have a high level of control, enabling bi-directional data exchange.

This allows for the creation of custom applications that extend functionality or reuse information for a wide range of purposes, such as enhanced product information for your Web CMS or e-commerce platforms.

When adding the API to our architecture, the updated diagram looks as follows:

Much like the web client, the API can be installed on IIS or as an Azure App Service. In many cases, both components are deployed alongside each other.

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

The API has proven over more than a decade that it's possible to expand Perfion's functionality without breaking the API interface. This means that upgrades can be performed without incurring additional costs for the development of integrations.

The API provides both Soap/XML and JSON syntax.

Application Server

The Perfion Application Server (PAS) is an addition to the architecture that has been introduced in 2020.

The PAS serves as a backend service designed to execute certain operations, independently of the end-user client. One example of its use is the generation of large product catalogs via the reports/publishing functionality. In this scenario, the web client will request the PAS to generate the report, allowing the user to continue working while the report is being generated. Once the process is complete, the result will be made available in the user’s "inbox" within the client.

Another common use case for the PAS is the scheduling of recurring jobs or actions. For example, the PAS can be utilized to run a nightly synchronization of data from an external source or perform other data manipulations automatically, without requiring user interaction.

This additional component fits into the architecture as shown here:

The PAS is a Windows-based service. It’s important to note that there is no direct communication between the web client and the PAS. Messages are transmitted via the database, which means that messages and requests are processed asynchronously.

A Perfion installation with the components depicted above (database, client, API and server) represents a standard configuration 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

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).