@@ -18,8 +18,10 @@ To avoid conflicts between library versions (e.g. Hazelcast).
6. In **UrbanPulse/UrbanPulseResources/** there is a file called **glassfish-resources.xml**. This contains information (in the form of Java Naming and Directory Interface short JNDI variables and connection pools) such as connection to the database, connection to a keycloak server (comes later), etc.
7. It is important to configure the connection to the PostgreSQL database in the **jdbc-connection-pool** section. I.e. enter user, password and if necessary database name (urbanpulse) and hostname/port of Postgres (if changed).
8. The command **asadmin add-resources {path to}/glassfish-resources.xml** will create the JNDI Variables
/Connection Pools angelegt.
8. The command **asadmin add-resources {path to}/glassfish-resources.xml** will create the JNDI Variables.
9. To verify the result, you can open the management page of Payara http://localhost:4848/ and under **Resources -> JDBC -> JDBC Connection Pools** you can see the pool from the configuration file. You can also test the connection by selecting the pool and then clicking on Ping. In addition, you can view the configurations for the database under the tab Additional properties.
16. The Inbound module is in the **/UrbanPulse/HttpInboundModule** folder. The inbound interfaces are the entry point for data from different data sources, which can be integrated with [ui!] connectors. To configure the module, it is best to insert the configurations in the database in the up_inbound_setup table a few times to be able to deploy the module multiple times - insert into **up_inbound_setup (setupjson) values ('{"receiverCount":1,"sendDestinations":["theCEP","thePersistence"]}‘);** The sendDestinations are the **Vertx addresses** or **Topics** where the received messages are sent.
15. The Inbound module is in the **/UrbanPulse/HttpInboundModule** folder. The inbound interfaces are the entry point for data from different data sources, which can be integrated with [ui!] connectors. To configure the module, it is best to insert the configurations in the database in the up_inbound_setup table a few times to be able to deploy the module multiple times - insert into **up_inbound_setup (setupjson) values ('{"receiverCount":1,"sendDestinations":["theCEP","thePersistence"]}‘);** The sendDestinations are the **Vertx addresses** or **Topics** where the received messages are sent.
16. That folder also has a **config.json** file, which contains additional information like host and port (where the data is received default is 40777), keystore and keystorePassword to secure the server.
17.That folder also has a **config.json** file, which contains additional information like host and port (where the data is received default is 40777), keystore and keystorePassword to secure the server.
17.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**
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**.
18. Open Command Terminal and run/execute the jar file individually from their build directories as below:
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.
20. 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):
21. 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.
22. 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.
23. 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.).
24. 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:
25. If everything is configured and started correctly, the **UrbanPulse Status Page** at https://localhost:8181/UrbanPulseManagement/status/ will look like this:
