Custom Business Logic

To allow businesses to customize the behavior of the Pricefx application to their specific needs, Pricefx provides its Logic API. Unlike the web API — which mainly revolves around data transfer — the Logic API permits businesses to let the application call their custom code under specific circumstances. Such usage of hooks is the primary way to customize the behavior of Pricefx.

Logics

A hook consists of a collection of Groovy scripts and a JSON file. Together, all these files make up a so-called logic. Although a logic is technically more than just a single JVM function — in practice — it acts just like one. When you execute a logic, you provide a set of inputs and is retrieve another set of results.

In production, the Pricefx backend application will call these custom logics when specific events are triggered. For example, during the calculation of a price list, the backend will call the configured pricing logic and map the output to the price list table cells. The pricing logic acts as a function that maps the product to a price.

But for development and testing, you can also call logics directly via the web API. To make this call simpler, Pricefx provides a plugin for IntelliJ IDEA that gives you a graphical user interface for executing logics in test mode.

Tech Stack

To develop efficiently with Pricefx, it is essential to be familiar with the various tools, services, and frameworks that Pricefx offer. This section is an overview of the technologies that you will need to include in your tech stack.

Figure 1. A schematic representation of the various technologies used in an example solution.

Groovy & JDK

Custom logic is written in the Groovy Programming Language. Since the code is executed remotely, you do not need to install Groovy or the JDK on your local machine. However, the Pricefx testing framework (TDD4C) does require code to be executed locally.

If you create a new project from the pricefx-starter template, the gmavenplus-plugin for compiling Groovy files is already included in the pom.xml file. (Together with TDD4C).

Integrated Development Environment (IDE)

Since custom business logic are created with Groovy, you will need a text editor. For an IDE, Pricefx recommends IntelliJ IDEA. Pricefx maintains a plugin for IntelliJ IDEA called Pricefx Studio. This plugin helps you maintain a valid Pricefx project structure, and valid json files. It also enables proper code completion, provides actions for creating logics, a graphical user interface for testing them, a control panel for deploying and fetching code and configuration files, and more.

There are no plugins for other IDEs, such as Visual Studio Code or Eclipse.

Version Control & Continuous Integration (CI)

To ensure that your configuration is consistently deployed, you should use a version control system (like Git) and set up a continuous integration (CI) pipeline. The pipeline should contain jobs that performs the following actions on merge to the origin branch.

Test

Test your custom logic with Pricefx’s testing framework TDD4C.

Deployment

Preferably deploy your custom logic with the Pricefx Packaging Tool. This is a command-line application that packages and deploys your configuration to the Pricefx backend. However, it does require your CI jobs to run on a private docker image (cregistry.pricefx.eu/tools/pfxpackage)

See the Pricefx Starter Project for an example of how to use the Pricefx Package docker image in CI/CD jobs.

Maven

You may also find the Pricefx Maven Plugin useful for development. The plugin provides goals to fetch, deploy, and remove data on the remote server. Unlike the packaging tool and Pricefx Studio, it can also fetch and deploy tables, price lists, quotes, and most other forms of data. In production, these forms of data is managed by a separate integration; but during development, it is easier to deploy mock data with the maven plugin.

The Pricefx Maven Plugin also has a task to clean all data on a partition. This is useful when you want to deploy your solution to an empty partition — to ensure that your project contain a full description of the remote environment. For example, if someone directly manipulates the develop environment — without committing these changes to Git — you may not see those changes reflected in the production environment when you later deploy your changes there.