Automation within Information Services Applications Team Delivers Efficiency Gains

Recent work within Information Services Applications has realised benefits by significantly reducing the amount of time required to release APIs (code used by developers to innovate and build further tools).

By utilising tools and technologies which partly automate the work involved in rolling out APIs the Development Services teams have managed to reduce the lead time prior to release from around five days to a matter of minutes.  The tools mean that the release process is significantly more straightforward and requires much less setting up and configuration to the point where releasing an API is almost a case of pushing a button.  The automation also ensures that the process is more reliable and less prone to errors.

Furthermore, multiple APIs can be released in parallel meaning that efficiency gains are further increased as more APIs are developed by the University.

The team demonstrated this new capability in a recent deployment of a microservices tool where several existing APIs were redeployed as part of the release.

Further Information on APIs Programme:

There is a need to transform the online experience of students, applicants, alumni, staff and other members of the University community to provide tailored information via personalised digital services.

To deliver these personalised digital services requires a way to plug into information from central systems and use it in new and innovative ways , like new websites, apps for mobile devices and what’s called ‘portlets’ for MyEd that operate like web pages within web pages.

Plugging into the information can be achieved by using Application Programming Interfaces (APIs). Here at the University we use open source tools for APIs – the type of code you can get from online communities where developers collaborate to make even better products and software.

While API technology has been around for a long time, its use beyond the integration of large, complex business systems has grown rapidly in recent years and with the proliferation of devices and mobile technology, API use in getting data from one place to another – from connecting business systems, to mobile devices and apps – has expanded exponentially.  That’s because APIs allow data to be accessed securely and consistently across multiple devices, a tremendously valuable resource for the University.

The University’s Enterprise APIs Programme (part of Digital Transformation) has been set up to deliver APIs to support projects like the User Centred Portal Pilot, the Service Excellence Programme and other digitalisation and transformation Programmes across the University.  In addition to enhancing central services such as MyEd, APIs will provide a consistent way for software developers across the University to build flexible systems at a lower cost, securely, and consistently across multiple systems.

Further Links:

Digital Transformation Website

API Technology Roadmap

 

Unit testing AngularJS portlet with Maven and Jasmin

Recently, we have converted a few portlets to use AngularJS for the front end.  We have also used the Jasmine framework for unit testing. Since our portlets are already configured with Maven, we have added Jasmine support with jasmine-maven-plugin to the existing set up. This posts will walk you through the configuration required to run Jasmine tests with Maven.

Portlet directory layout

|—— Portlet
| |——– src
| | | ——– main
| | | | ——— webapp
| | | |————- js
                              app.js
| | | ——– test
| | |———— webapp
| | | |————- js
                              controllerSpec.js

Our angularJs files are contained in src/main/webapp/js directory. Jasmine spec files are placed in a test directory that reflects main.

Plugin configuration 

Based on the directory structure, we can configure jasmine-maven-plugin. we are using version 2.0 which requires Maven 3.1.x. This is an example plugin configuration for our portlet:

<build><plugins>
    …
    <plugin>
       <groupId>com.github.searls</groupId>
       <artifactId>jasmine-maven-plugin</artifactId>
       <version>2.0</version>
       <executions>
          <execution>
             <goals>
               <goal>test</goal>
             </goals>
          </execution>
       </executions>
 <!-- keep the configuration out of the execution so that the bdd goal has access to it -->
       <configuration>
           <jsSrcDir>src/main/webapp/js</jsSrcDir>
           <sourceIncludes>
               <include>app.js</include>
           </sourceIncludes>
           <jsTestSrcDir>src/test/webapp/js</jsTestSrcDir>
           <specIncludes>
               <include>*Spec.js</include>
           </specIncludes>
           <preloadSources>
               <source>webjars/angular.js</source>
               <source>webjars/angular-sanitize.js</source>
               <source>webjars/angular-mocks.js</source>
               <source>webjars/jquery.js</source>
           </preloadSources>
       </configuration>
 </plugin></plugins></build>
<dependencies>
 
<!-- jasmin maven plugin dependencies -->
 <dependency>
      <groupId>org.webjars</groupId>
      <artifactId>jquery</artifactId>
      <scope>test</scope>
 </dependency>
 <dependency>
      <groupId>org.webjars</groupId>
      <artifactId>angularjs</artifactId>
      <scope>test</scope>
 </dependency>
<!-- for headful tests
 <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-firefox-driver</artifactId>
      <scope>test</scope>
 </dependency>
 -->

 </dependencies>

<jsSrcDir>  points to diectory with your JavaScript, this will be your angular controllers, directives, filters, etc.

<sourceIncludes> specifies which files within jsSrcDir should be included and in which order (added sequentially as defined)

<jsTestSrcDir>  points to directory with your Jasmin specs

<specIncludes> specifies which spec files to include and in which order

<preloadSources> JavaScript files to be loaded before the application files and specs, added sequentially as defined; these should be all libraries that you need for your application e.g. angular files, jQuery etc. We can reference webjars files here as done in our example. Since we require them for the tests only, we reference them in the test scope.

Out of the box, jasmine-maven-plugin comes preconfigured with PhantomJS for headless tests. For headful tests, configure the plugin with a different driver, such as:

<webDriverClassName>org.openqa.selenium.firefox.FirefoxDriver</webDriverClassName>

Usage

Jasmine can be used for TDD (Test Driven Development). Run

mvn jasmine:bdd

This will fire off the browser at http://localhost:8234 and run the specs from the test directory whenever you refresh the page. This will give you an immediate feedback as you develop your angular controllers etc.

Running

mvn jasmine:test

will run the headless tests by default, unless configured otherwise.

Running

mvn clean test

will run all your tests in the portlet, including Jasmine headless tests provided there were no test failures before.

With this configuration we are now ready to write Jasmine specs for our portlets.

Creating a skeleton Spring MVC Portlet

If you’re needing to create a new JSR-286 portlet, the Apereo Foundation (formerly JASIG), have provided a Maven Archetype for the creation of a skeleton portlet.

Essentially you can run the following command:

mvn archetype:generate -DarchetypeGroupId=org.jasig.portlet.archetype -DarchetypeArtifactId=jsr286-archetype

It will ask you for the group, artefact and package information, and will automatically create a skeleton Spring MVC Portlet for you.

See the using the uMobile Portlet Archetype article for full details.