Legacy Product

Fusion 5.10
    Fusion 5.10

    Develop and Deploy with App Studio

    This topic shows you the App Studio workflow from initial app development through deployment into Fusion.

    This procedure does not apply to App Studio Enterprise (ASE).

    Development tools and workflow

    In building out a search application, App Studio developers use the following tools:

    • an IDE (Intellij, eclipse, VS Code, and so on)

    • Maven for server-side dependency management and its integrated Jetty plugin

    • NPM for client-side dependency management

    • Java 1.8 JDK

    The high-level development workflow looks like this:

    1. Clone the repository of our project on our local system.

    2. Make additions and edits to the code which we then commit to the repo.

    3. 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.

    1. Build a profile (optional)

    For each environment, we can build out a profile to overlay specific parameters to this environment:

    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.

    For more details, see "Package the web application for different runtime environments - build profiles" at https://dev.twigkit.net/docs/Getting_started/Installation/Building_from_source/?q=profile.

    2. Configure the profile (if any)

    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 should point to the query profile that manages the main collection to which we want to send signals. For example, if we specify a query profile that points to the myCollection collection, then App Studio sends signals to the myCollection_signals collection (if it exists).

    • 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.

    • 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 where 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, and so on). The password parameter is the key that is used when hashing passwords using the 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 web apps or local logs. The main logging comes from the root package twigkit.

    3. Package the app

    To deploy our code to the server, we use Maven to create a WAR file:

    • If you are using a build profile as described above, run mvn clean package -Dtwigkit.profile=profileName.

    • If you are not using a build profile, run mvn clean package.

    You can watch the logs for any compilation errors.

    Rename the resulting WAR file to ROOT.war, if it is not already named this way.

    4. Deploy the app

    Before you deploy an app, make sure that both of these prerequisites are met:

    • Fusion is installed.

    • A Fusion app is created.

    Deploy the web app as follows:

    1. Create a new App Studio context in Fusion by executing the following command as a user who has admin rights:

      curl -v -u USERNAME:PASSWORD -H 'Content-type: application/json' -X POST 'http://localhost:8764/api/apollo/apps/my-fusion-app-name/webapps' -d '{"id": "myasapp","name": "My AS App","contextPath": "/"}'

    2. Upload the WAR to the Fusion Webapps service:

      curl -v -u USERNAME:PASSWORD -H 'Content-type: application/zip' -X PUT 'http://localhost:8764/api/apollo/apps/my-fusion-app-name/webapps/myasapp/war' --data-binary @ROOT.war

      This puts the WAR file into the Fusion blob store, and tells the Webapps service that this is the file that should be started in the specified context.