Fusion App Studio

​

Development tools and workflow

• an IDE (Intellij, eclipse, VS Code, and so on)
• Maven for server-side dependency management and its integrated Jetty plugin
• NPM 9.0.2 for client-side dependency management
• Java 1.8 JDK

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.

​

Build a profile (optional)

​

Configure the profile (if any)

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

​

Package the app

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

​

Deploy the app

• Fusion is installed.
• A Fusion app is created.

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

   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:
   Copy

   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.

​

Opening the code editor

• Press the ESC key or
• Click the code editor button:

​

The toolbar

​

Saving your changes

​

Publishing your search interface from the code editor (version 4.0)

1. Configure Fusion:
   1. In Fusion, navigate to Querying > Query Pipelines.
   2. Select the query pipeline you are using.
   3. Select the Solr Query pipeline stage.
   4. Under configure Request Handlers Allowed for Queries, click Add .
   5. Enter “Terms”.
   6. Click Save.
      Unlike the Suggest component, you do not need to modify solrconfig.xml to use the Terms component; it is preconfigured.
2. Configure App Studio:
   1. Open config/services/suggestions/terms.conf. Its default content is as follows:
      Copy

      name: twigkit.search.solr.suggestions.SolrQueryTermsService
      source: platforms.fusion
      
      # List out all fields to base your terms suggestions on
      term-fields: title
      title:
      

   2. Change the default source: platforms.fusion to source: platforms.fusion.data.
   3. Edit the value of term-fields as a comma-separated list of fields in your data from which to retrieve terms.
      This corresponds to Solr’s terms.fl parameter.
   4. Edit the value of title to describe the group of suggestions returned by Fusion. This title can be used to group suggestions in the UI. If you are implementing only one group of suggestions, you can leave this blank or set it to something generic, like “Suggested phrases”.
   5. Save and close the file.
   6. Open app/views/partials/header.tpl.html.
   7. Uncomment the following line:
      Copy

      <query-suggestions completion-service="services.suggestions.terms" action="/search"></query-suggestions>
      

   8. Save the file.
3. Refresh the search UI in your browser.
4. Test the feature by typing a search phrase. App Studio now displays suggested terms on the fly: