CASE STUDY

Industry automation

Setting up web applications to govern the supply management of a large production industry.

OpenShift

TypeScript

Drools

MongoDB

Microservices

INTRODUCTION

Schindler Electronics Ltd. is a global manufacturer and supplier of high-end lifts/elevators.
They have a complex supply chain, where every new order generates a multistep process. In such a high demanding context, there is a strong need for software applications to accompany the journey from order to final delivery. WellD partnered with Schindler to develop multiple systems serving different requirements, as in the example below.

CHALLENGE

An elevator is a complex product. If we think about it for a minute we can clearly see it is far more than a steel box going up and down a rail. Beyond complex mechanics and cables, it has many control panels at each floor, internal commands, lights, indicators, and security components.

All these materials must be properly configured and selected from a list of thousands possible alternatives, with each selection potentially ruling out other options, or making additionals appear. Product engineers at Schindler are dedicated to this delicate task to generate a final list of materials needed to build up the elevator.

To rule this complexity, WellD was asked to implement a dynamic web application called Fixture App, to enable operators to manage elevators orders and configure all the needed components.

The main challenging requirements were:

Dynamic generation of the configuration flow
Integration with a rich Bill of Materials
Management of complex pricing and discounting rules

An elevator is far more than a steel box going up and down a rail

SOLUTION

For this project, we had to solve two main technical challenges:

We needed to implement multiple configuration flows for the different components of an elevator. Furthermore, it was important that Schindler engineers could update configurations without touching the codebase.
Likewise, we needed a way to describe the complex business rules to select the correct materials for a given configuration. The rules would also change, as engineers add new components to elevators and available materials change;

To solve the first challenge we designed a DSL that can describe a component configuration flow in a declarative way.

A Workflow Generator service digests the component configuration to produce a JSON version of the flow. When engineers configure a new component, the User Interface (a single page app written with ReactJS) interprets the JSON tree and draws a wizard to complete the configuration. After the engineer has configured the component, the system should produce the respective bill of materials.

As for the configuration flows, material selection rules need to be updated by non-coders. To achieve this, we relied on the business automation capabilities offered by Drools and the Business Central; we laid out the rules in Guided Decision Tables, and implemented a custom Maven plugin to run them on a Kogito microservice.

The application of the microservices pattern proved to be effective for this project. We were able to choose the best technology for the task at hand:

Kotlin for the DSL;
Java for interacting with Drools;
Node.js and GraphQL to expose the public API consumed by the UI.