18. To start the inbound you can use **run.bat** or **run.sh**. It is important that each module contains a valid **-Dvertx.hazelcast.config=..\default-cluster.xml** so that the Hazelcast service discovery can work. Example config under **/UrbanPulse/default-cluster.xml**.
19. The module consists of a Complex Event Processing Engine and some configuration elements. The task of the CEP module is to receive and analyze events from the other platform modules to perform temporary analysis against the moving event stream.
20. You need [Esper library (esper-5.2.0.jar)](https://jar-download.com/artifacts/com.espertech/esper/5.2.0/source-code) to start the **EventProcessor** locally. This must be stored here: **/UrbanPulse/EventProcessorModule/target/libs**
21. As with the **inbound**, there is a **config.json** file, as well as **run.bat** and **run.sh** files. Again it is important to use the correct Hazelcast configuration, otherwise no additional configuration is needed.
22. The **Persistence Module** can use existing storage solutions or services and collects the heterogeneous events to store them in a distributed storage. The Persistence Modules abstract from the storage implementation and also have the possibility to configure a hierarchical storage implementation, which allows to combine the advantages of different storage systems.
23. To configure the module you have to enter the following in the database (don't forget user and password):
24. The modules of the outbound interface layer are responsible for data distribution and provisioning. They embody the interfaces between the platform backend services and the client applications. The **UrbanPulse Outbound Interfaces** can be seen as a facade for the urban data sources and analytics services.
25. Important for the outbound is the config.json file in the folder. Here you have to configure the database once (username and password in **MainVerticle.security.jdbc** and **MainVerticle.upServiceConfig.jdbc**). This is needed by the **Outbound** to authenticate and authorize users who want to connect to the Historical API or to the WebSockets.
26. At **wsServerConfig** you can see which **ports** and which **host** are used for Websockets. At **historicalDataRestConfig** you can see the configuration for the **historical API** (port, rules etc.).
27. If everything is configured and started correctly, the **UrbanPulse Status Page** at https://localhost:8181/UrbanPulseManagement/status/ will look like this:
**Default Admin Password** – obviously the default password for a production deployment is not secure. To solve this problem, one can define a new password for the admin user via the APIs.
**APIs** - https://localhost:8181/UrbanPulseManagement/docs/ is a good place to get info about the existing endpoints of [ui!] UrbanPulse. In addition, the schema of the response or body is also displayed.
**Payara CLI Commands** – List of the commands that can be used to operate Payara https://blog.payara.fish/administering-payara-server-5-with-the-cli
**Payara in Netbeans** – Guide for how to use or debug Payara directly in Netbeans https://blog.payara.fish/debugging-diagnose-and-detect-the-cause-of-errors-in-your-application
**Payara debug with Intellij** – make sure that the debug port is open. **Run/Debug Configurations -> Add new Configuration (+ above left)-> Remote**
