How to Configure IntelliJ IDEA to Work on a DOC 4.0 Application

IntelliJ IDEA is the recommended IDE to develop applications based on DOC 4.0. It is indeed a well adapted tool when working on Docker/Angular/Spring Boot based microservices applications. In this article, we will show you how to take advantage of these features to create a comfortable development environment to work on your DOC 4.0 applications. We will focus on two aspects: how to configure the Services Tool Window to give you control of all microservices in a single graphical user interface, and how to configure database explorers to work with your business data.

Prerequisites

To follow this tutorial, first, make sure that your development environment satisfies the requirements described in the documentation for version 4.0.1.

If you do not have a DOC application in version 4.0.1 already, follow the quick start guide to generate a new one.

Finally, you need to have installed the Ultimate edition of IntelliJ IDEA. Indeed, some of the features that we will use in the next sections, such as the database explorers and some types of run configurations are not available if you are only using the Community edition. Make sure that the Services tool window is activated and that Docker, npm and Spring Boot run configurations are available. You can follow these instructions if it is not the case.

Configuring the Service Tool Window

This section describes the configuration of run configurations for all the microservices that constitute the three layers of a DOC application: the infrastructure layer, the Optimization Server layer and the application layer.

Control the Infrastructure Layer

The infrastructure layer is the foundation of a DOC application. It is the layer handling data persistence (PostgreSQL and MongoDB), message brokering (RabbitMQ) and user management (Keycloak). These are all community maintained open-source projects that are used as external dependencies in your application.

You do not need to configure any of these components to run your application since a scaffolded application provides a docker-compose configuration file to deploy them as pre-configured docker containers.

To deploy this docker-compose configuration, you could use the docker-compose command-line interface, but it is also advantageous to define a docker configuration in the IDE that will provide a graphical interface to control and monitor the deployment.

To achieve this, create a Docker-compose run configuration, give it a name (eg. “infra”), select ./deployment/docker/infra/docker-compose.yml as a compose file and activate all four services (keycloak, mongo, postgres and rabbitmq). You may also be interested in selecting the option “— volumes, remove volumes on `down`” if you want to dispose of the volumes used by the postgres and mongo services when you take them down, for example, if you always want to get empty databases after redeploying the infrastructure.

Now that your configuration is ready, it should show up as a new entry in the Services tool window, under the “Docker” category, with a button that lets you “start” the deployment of all four services in one action. Once the deployment is started, it will appear in a second “Docker” category where you will be able to perform more actions (such as “up”, and “down”), and monitor every container:

Control the Optimization Server Layer

The Optimization Server layer is a complete Optimization Server application made of three components: an Optimization Server master (responsible for orchestrating worker tasks), an Optimization Server documentation component and an Optimization Server Web UI. It relies on several components of the infrastructure: Keycloak, MongoDB and RabbitMQ, and thus it should be deployed once the infrastructure layer is operational (you can check the logs of each container on the services tool window to make sure every one of them is ready, Keycloak generally being the one with the longest startup time). The Optimization Server is also used as an external dependency in a DOC application, and thus it is expected to be deployed as Docker containers.

The procedure to deploy the Optimization Server layer is also based on docker-compose, and thus is very similar to the procedure we have just described to deploy the infrastructure. Create a second Docker-compose run configuration (name it for example “dbos”), and this time select ./deployment/docker/dbos/docker-compose.ymlas the compose file, and activate the dbos-master service. You can also activate the two other services dbos-documentation, and dbos-web-console, but these are not mandatory to run a DOC application.

Again, once started, you will be able to interact with the containers directly in the Services tool window.

Control the Application Layer

The Application layer is made of many components: gateway-service, scenario-service, data-service, backend-service, execution-service, the Web UI and a collection of workers. All these components could be customized to implement specific features in your application. There are two possibilities to deploy the Application layer: either as docker containers, following the same procedure as for the Infrastructure and Optimization Server layers, or by configuring run configurations for each component.

If you go for a docker deployment, create a third Docker-compose run configuration (for example, give it the name “app”), and select the Compose files ./deployment/docker/app/docker-compose.yml and ./deployment/docker/app/docker-compose-workers.yml, and activate all services.

However, in order to get a better developing experience, it would be preferable to execute these components directly on your machine rather than re-packaging them every time you make a change to redeploy the updated container. To do so, the solution is to define a “npm” (for the Web UI) and “Spring Boot” (for all the others) run configurations for each component.

Since version 4.0.1, sample run configurations are generated with the project and located in the .run folder. You can use these configurations as a base for your own. However, it is advisable not to commit them in the project, since every user should be able to define and configure his own run configurations according to his environment and his needs. However, we will still describe in detail how you can create these configurations from scratch.

We can start by configuring the Web UI as it is the only one based on an “npm” run configuration. For this, create a new “npm” run configuration pointing to the package.json file located at ./web/package.json. and running the script start. Also, you should set yarn as the package manager if this is not already the case. The configuration should look similar to this:

Apply the changes and a new entry should appear in the Services panel to let you control this web application.

We can now configure all the other services, which are all based on Spring Boot. We can start with the data-service. Create a new “Spring Boot” run configuration named data-service, select com.decisionbrain.gene.data.application.DataService for the main class, and in the environment section, and select your-project.gene-services.data-service.main for the “Use classpath of module” option.

Since version 4.0.1, all service main classes no longer located in the service modules, but are provided in external dependencies. As you can see in the previous screenshot, IntelliJ IDEA is not able to find these main classes. This is currently a bug from IntelliJ IDEA that prevents the IDE to find the main class located in an external dependency, but despite the error message, you will still be able to add and use the configuration.

Once you apply the modification, a new data-service entry should appear in the “Spring Boot” section of the “Services” panel.

The remaining components are configured in a similar way. The following list describes the main class and the “Use classpath of module” option for each service:

For your workers, the configurations are simpler, since you only need to create a spring boot configuration with the workers’ main class which are defined in their own module. For example:

• your-package.worker.CheckerWorkery
• your-package.worker.EngineWorker

Explore Databases

Using database explorer can be useful when developing web applications, for example, to insert testing data, or for debugging, when you need to check your database to identify data-related issues. Fortunately, IntelliJ IDEA comes with integrated tools to work with databases. This last section will describe how you can configure these tools to work on your custom application data.

We will focus on the only two databases that may contain custom business data: the data server database and the scenario database. Other databases are used in a DOC application, such as the database used by Keycloak, or the databases used to store information about jobs by both the execution service and Optimization Server. Since these databases are not the support for any custom application data, they are not addressed here.

Access to Domain-Specific Data

The most useful database to explore in a DOC application is the data server database. This is the SQL database that contains all your business data related to the data model that you have defined in the JDL file, and which are all instances of entities contained in the scenarios created by the user.

It is deployed in the PostgreSQL server that is part of the infrastructure layer, and therefore we can configure a PostgreSQL data source in IntelliJ that lets us interact with the data using tabular views or SQL queries.

To configure this database explorer, go to the database tool window and add a new PostgreSQL data source. If you are using the default docker configuration to deploy the infrastructure, then you can directly configure the data source with the following properties:

• host: localhost
• port: 5432
• user: data_server
• password: value of the password assigned to the user data_serverin the SQL script located at ./deployment/docker/infra/postgres/start/10-create_user.sh
• database: data_server

Access to Scenario Related Data

Another database that is useful to explore is the scenario database. It is a Document-oriented database that contains metadata about all scenarios (name, creation dates, etc.), but despite its name, it also stores the view and dashboard structure of the application. You can also add custom data here since you can add custom properties in a scenario, for example, to introduce a status property related to your application flow.

This database is served by MongoDB, which is also supported as a data source in IntelliJ IDEA. Thus, to explore this database, you can simply add and configure a new MongoDB data source with the following properties:

• host: localhost
• port: 27017
• user: scenario
• password: value of the environment variable MONGODB_SCENARIO_PASSWORD declared in ./deployment/docker/infra/docker-compose.yml
• database: scenario-db

The support for MongoDB in IntelliJ IDEA is still recent and does not provide already a way to edit data directly in JSON documents. You may want to supplement it with a full-fledged MongoDB data explorer such as MongoDB Compass. However, it remains a practical tool to visualize the documents stored in the database.

Conclusion

If you have followed all these instructions you should now be able to control all the microservices that constitute your application in the Services tool window, such as it is in the following view:

You should also be able to explore and edit your data without leaving IntelliJ IDEA.

These tools should greatly improve your development experience while working on your DOC 4.0 application.

IBM® Decision Optimization Center provides a configurable platform for building, deploying, and monitoring decision support applications for business users.

Learn more about IBM Decision Optimization Center

Learn more about the Optimization Server