App Studio Development & Deployment Guide

In building out a search application, App Studio developers use an IDE (Intellij, eclipse, VS Code), maven for server-side dependency management and its integrated jetty plugin, NPM for client-side dependency management and Java 1.8 JDK.

We first will clone the repository of our project on our local system. From there we make additions and edits to the code which we then commit to the repo.

In order to test our changes in real time, we use the integrated maven jetty plugin to serve up our local application at http://localhost:8080 where we can see most changes made to the code in real time.

For each environment, we build out a profile to overlay specific parameters to this environment. See the section entitled ‘Package the web application for different runtime environments - build profiles’ here for more details: https://dev.twigkit.net/docs/Getting_started/Installation/Building_from_source/?q=profile

Example command: mvn clean jetty:run -Dtwigkit.profile=profileName

In App Studio apps, we can have different profiles for each environment (Dev, QA and Prod) as well as local development. These profiles contain configuration files that should overwrite the files with the corresponding names and directory locations in the main resources directory.

Following are the files you may want to specify for a given environment in each profile:

message.service.fusion.conf – This config file is responsible for the configuration of the way we send signals to the Fusion endpoint. The important property here is query-profile, which we should ensure points to the query profile that manages the main collection to which we want to send signals. I.e. – if we specify a query profile that points to the myCollection collection, App Studio will send signals to the myCollection_signals collection (if it does exist).

platforms.fusion.fusion.conf – This is our base Fusion platform configuration file. It manages all the configuration settings that are common amongst each Fusion platform. These settings are inherited by any config file in the platforms.fusion directory, as this file has the same name as the directory it resides in.

platforms.fusion.data.conf – This is our configuration file for the main platform, by default. The only required parameter is the query-profile to send these queries to. This is included in the profiles as during the course of development, there were some differences across environments in the name of this collection, so we set them individually for each environment.

The important property to note here is query-profile which tells App Studio which query profile to fire search requests against.

security.kerberos.conf – This is an example of a security configuration file. In this case, the file in which Kerberos security is configured. The parameters set here are referenced in our configuration of resources/spring-security.xml when the app is loaded. The main parameters to understand are service-principal and keytab-location. The service principal should be the one used when creating the keytab file. The keytab location is the location in which the keytab resides on the server that App Studio is running.

security.security.conf – The function of this file is to set general parameters related to security. The type parameter should be the type of security your app should use (kerberos, spring_security, saml etc..). The password parameter is the key that is used when hashing passwords using twigcrypt utility. It is to be used in combination with a ‘secret seed’ in order to generate the hash.

services.api.fusion.conf – This is the main file in which the connection to the Fusion API is configured. ­The host, port and protocol values are all given independently. The credentials given are that of a service account that has POST rights to enable the sending of signals to Fusion.

logback.xml – In this file, we can add additional <logger> tags to print out additional logging on specific classes in the webapps or local logs. The main logging comes from the root package twigkit.