Summer Student Work Project Report

Author: Branislav JencoSupervisor: Adrian FabichDuration of stay: 4th of July - 9th of September

Department: EN-EA-LE7th of September, 2016

ContentsGeneral thoughts about the programme...............................................................................................3

Work Project..........................................................................................................................................4

Work Log...............................................................................................................................................5

Web Application Usage.........................................................................................................................7

Status Tab..........................................................................................................................................7

Timeseries Tab...................................................................................................................................7

Wirechamber Tab..............................................................................................................................8

Appendix: Technical documentation of the web application................................................................9

Back-end overview:...........................................................................................................................9

Dependencies:...............................................................................................................................9

Web Application Start-up..............................................................................................................9

Sidenote: Structure of the configuration.xml file..........................................................................9

Application start-up (continued)..................................................................................................10

Servlet Responsibilities................................................................................................................11

Front-end overview.........................................................................................................................12

How to set-up a development environment for the SBA-Beams source code.................................14

How to use the Java Server Administration Page (“Java Middleware on Demand”)...........................15

Administration within the CERN Web Services Management.........................................................15

The Java Middleware on Demand Administration Application........................................................16

Container level.................................................................................................................................16

Container Logs page....................................................................................................................18

Application Level.............................................................................................................................18

Actions in the Application View:..................................................................................................19

View Properties Page...................................................................................................................20

Workflows.......................................................................................................................................20

Editing the configuration.xml file.................................................................................................20

Deploying a new version of the application.................................................................................20

Important links summary....................................................................................................................21

General thoughts about the programmeI’ve spent twelve weeks here at CERN and in that time, I met more new people than

probably in a year or more before. I feel very grateful for the opportunity to experience the summer here, be it attending the lectures, working on my project, going to trips and hikes or generally socializing. It’s a great experience not only professionally but also personally. I am most thankful to my supervisor Adrian Fabich and everyone else I worked with for a great, friendly work environment.

In the first five weeks of my stay, I had attended a large portion of the morning lectures given in the Main Auditorium. Being a Computer Science student, several of the lectures that required undergraduate knowledge of Physics were over my head, and soon I began to pick and choose which lectures I would attend, choosing to spend the time working on my project instead if the lecture seemed incomprehensible to me. The ones I usually attended were more focused on engineering and computing. I was also keeping an eye on the Openlab IT lectures that were happening in the afternoon, and attended a several of those instead of the morning lectures. In my opinion, these were some of the most interesting ones and I feel like I could do with much more of them. That is only natural given my field is not Physics. I would have also liked to attend the first week of the lectures, since they started before I arrived, but I understand that it’s not possible to schedule everything perfectly for so many incoming students and the recordings are available.

The most interesting lectures for me were the series of “From Raw Data to Physics” by Anna Sfyria which dealt with the processing of data collected in the accelerators, “Superconductivity and SC Magnets for the LHC Upgrade” by Paolo Ferracin which provided an interesting in-depth look into the engineering problems of superconductivity and also the series of lectures on “Cosmology” (Ruth Darrer) and “Astroparticle Physics” (Laura Covi), since space physics and space exploration are fields I am very much interested in particular. I also found the closing lectures on Gravitational Waves interesting and topical. I would also like to highlight the “Machine Learning” Openlab lectures by Sergei Gleyzer.

The stand-out experiences of the summer (within CERN) were definitely the tours. This includes the tours organized by the Summer Student Team as well as tours that were organized by the EN Department at the beginning of my stay and the tours organized by my supervisor. I have been in some very interesting places and learned a great deal about the operation of the facilities here as well as the history of CERN.

Work ProjectI had been working in the EN-EA-LE department under the supervision of Adrian Fabich. The nature of my project was the development of a web application that displays information about beamlines installed in the CERN Experimental Areas (North Area, East Area…). Specifically, the application is split into three parts:

1. Status View – the user can view the status of a chosen beamline within in these areas, meaning the last measured values for pre-determined variables

2. Timeseries View – the user can display a time series plot for one of the variables within the variable hierarchy in 4 prepared intervals – hour, day, week, month

3. Wirechamber View – the user can display the latest wire chamber profile plot for a chosen wire chamber

My goal was to make this application easy to use, reliable, easily extendable after my leave and accessible from anywhere on the web. The application can be found on the official CERN website http://cern.ch/sba-beams.

During my stay here my supervisor also provided me an opportunity to take part in a secondary project, which involved playing around with a small USB Timepix Pixel Detector. I had several meetings with Michael Campbell from the CERN Microelectronics Group and the leader of the CERN Medipix Team about the detector, in which he showed me its capabilities. I have played around with trying to catch cosmic muons and was going to test it with some radioactive sources but lack of time prevented me from pursuing this project further (such as creating a presentation about radiation using this detector as a probe).

Work LogWeek 1

The first week was spent mostly acquainting myself with the project, searching for possible technologies to use and setting up my development environment on my desktop computer in my office. While client-side it was definitely going to be a combination of HTML/CSS/JavaScript, on the server-side I was deciding between going the Java Servlet route or using a Python framework such as Django or Flask. Some of the requirements of the application, as well as the conditions of CERN Web Services combined with the fact that the API access to get the database data is in Java made me go the Servlets route.

Week 2

Once I have decided on the rough architecture of my application, I have started experimenting with chosen technologies and started building up small test applications on my local machine. I was deciding between using a Java framework like Spring or Play, but in the end elected to not use any for a simple application of this type. Heavy frameworks could only bring more complexity than what was needed.

Week 3

Even though I had experience with Java, I had not used Java Servlets before that point, and I had to learn their architecture and use from scratch by doing the aforementioned small testing applications. In this week I have also managed to run the application on test server within CERN Web Services (specifically Java Middleware on Demand service). I had also been exploring how to implement several of the functionalities the application had to provide.

Week 4

My supervisor gave me some further details on what the application should do specifically, and I set out to implement the features in rudimentary form. I had also started the migration process to an official website that would be open to anyone to use. This week was spent creating the functions on the server-end that would call the API methods and process data into their JSON representations.

Week 5 – 6

Apart from the server-end functions I began creating the JavaScript code for the front-end of the application and by the end of week six I had functional applications for the beamline status page and time series plot. I presented my work at a group meeting and took several suggestions for features and modifications.

Week 7-10

In these weeks I had finished migrating the website to the official (cern.ch/sba-beams) location. I had implemented most of the features that were brought up in the group meeting and cleaned up the JavaScript code into a more modular architecture. I had also created a configuration.xml file in an AFS file system folder which is tied to the web application and from which the application reads important configuration properties on start-up. Changing the beamlines and groups in the status page is therefore only a question of modifying this file according to the guide I provide and restarting the application. In these weeks I have also spent some time playing around with the Timepix Detector.

Week 11-12

The last two weeks were spent on writing documentation, proper code commenting, catching bugs and doing other minor adjustments.

Web Application UsageUpon visiting the http://cern.ch/sba-beams link, the user is presented with three tabs, which represent the three different functionalities the application provides.

Status Tab This view can display the status of a selected beamline. By status, we mean the last recorded values that were measured in various parts of the beamline. After the user picks a beamline and clicks the Submit button, the website queries the database for necessary data. When it gets them, it displays all of them in a fluidly distributed table. The table is divided into the respective variable groups of the beamline.

In the top bar you can see the time that the data was received and displayed, in local and UTC time, as well as the name of the selected beamline. Inside each group, all variables which are of NUMERICAL data type are shown with their names and values. These values are presented in scientific notation in the case of scintillators and Exp. Scalers variable groups. All variables are also rounded to two decimal digits. Variables which have a MEAS (measurement) and REF (reference) version are called pair variables. These pairs are always grouped together into one box of the table with both values displayed after the MEAS/REF keyword.

Notably, if there is a difference between the two values of a pair variable which is greater than a predetermined amount (differs for each group), the corresponding box for this variable is drawn in red to signalize this issue.

If the variable (or one of the variables in a pairing) has no data, their corresponding box is drawn in orange to signalize this issue. There are two checkboxes in the top bar which you can use to show only variables with either of these issues present and hide the rest.

The notion that some variables have no data stems from the fact that the application (or, more accurately, the database API) always looks at most one week behind for recorded data. If it doesn't find any recorded values, it doesn't return anything. This is done to reduce the load times, which become quickly unbearable when there are variables with no recorded data in more than a year. The interval of one week lookback time was picked as a compromise between speed and the amount of data to be shown.

When hovering with a mouse on a variable box, a bigger box with some further details about the variable/variable pair is shown. Here you can find their complete name, and also the timestamp corresponding to the value recorded.

Clicking the value of a variable itself will bring a timeseries view for this variable in the interval of one hour, using the other Timeseries tab of our application.

Timeseries TabIn this view, the user can choose one of the beamlines (technically one of the children nodes inside the SPS-EA and EAST HALL parent nodes in the variable hierarchy). Once he does that, the second dropdown of all variables within this node can be used to pick the specific variable. After setting the interval (hour, day, week, month) and clicking Submit, the application will query the database for the timeseries data of chosen variable and, upon receiving it, display it in the form of a chart. This chart is interactive and can be freely zoomed and moved about. The top right corner of the chart holds some options and tools that the user can use with the chart. (e.g. exporting the chart as a png)

Wirechamber TabIn this view, the user can pick from all the wirechamber profiles that can be found within the variable hierarchy. Upon clicking Submit, he is presented with the graph of the latest data vector from this wire chamber.

Appendix A: Technical documentation of the web applicationBack-end overview:The server side code of the application is built in Java, using some features version 1.8 (notably the forEach loop). It is using the Servlet API (https://en.wikipedia.org/wiki/Java_servlet) for processing HTTP requests and responses with the client. It is not using a framework such as Spring or Play. As such, the app is built as a .war, not a .jar package, and must be deployed in a Tomcat Servlet Container, targeted version 7.0.

The choice of Java and its Servlet API was made because of the fact that the API which provides access to the logging database is natively built in Java, and downloadable as a .jar file. For more information https://wikis.cern.ch/pages/viewpage.action?pageId=54067820#DataExtractionAPI/TIMBER-ProgramaticDataExtraction

The Tomcat web app container was chosen because of the fact that Tomcat 7.0 is the container and version which is running on the CERN Java MiddleWare On Demand service. Technically it could be run on other versions as well.

As the GET requests come in to the Servlets, these in turn call functions which fetch data from the CALS API and the process it, finally sending it in an HTTP response as a JSON file with pure data. All HTML rendering and visualization procedures (the VIEW in the MVC of the application) are done on the front-end with JavaScript (with the help of jQuery).

Dependencies:- Google GSON library (for converting objects into their JSON representations, is in the central

Maven repository)- CALS logging API library (for accessing the database, for all info & download see

https://wikis.cern.ch/pages/viewpage.action?pageId=54067820)- Servlet API for the Servlet functionality (is also in the Maven central repository)

Web Application Start-upUpon starting the application, the Tomcat container initializes the ServletContext object which is what we listen for in the method contextInitialized of our class ContextListener. Once invoked, the application accesses a configuration.xml file that is located in the AFS folder "/afs/cern.ch/project/jps/reps/sba-beams/" that is associated with the application (this association was done via the Java Middleware on Demand administration page).

Sidenote: Structure of the configuration.xml fileThe configuration file is structured into three parts, with the <configuration> node being the top-most all-encompassing parent node. Within this node, there are three nodes:

<beamlines>

<timeseriesParentNodes>

<excludeNodesWithWords>

1. <beamlines>

Within this node, we define all beamlines that we want to use in the status page, and all the variable groups for a respective beamline inside it. A beamline is declared using a new <beamline> node with

a parameter of name that we want to give to the beamline. The name parameter given here determines the title of beamline everywhere in the app. Within this node, we can put an arbitrary amound of nodes that are named as we like - their names will be eventually displayed as titles of the groups of variables on the status page. The contents of this variable group node must be the full path to this variable node in the hierarchy that exactly corresponds to Timber (case-sensitive). This also means that inside a beamline node, we can put variable groups which technically don't belong to the beamline in the hierarchy, like we do with H2 and T2.

Ex.

<beamline name=H2>

<magnets>SPS-EA->H2->MAGNETS</magnets>

...

</beamline>

2. <timeseriesParentNodes>

Within this node, we define <node> tags which serve as the base, top-level nodes in the variable hierarchy from which we start our generation of the variable hierarchy.

Ex.

<timeseriesParentNodes>

<node>SPS-EA</node>

<node>EAST HALL</node>

...

</timeseriesParentNodes>

3. <excludeNodesWithWords>

Within this node, we can put an arbitrary amount of <word>, their content being a phrase or a word, which, if a variable hierarchy node contains, we exclude it from our generated variable hierarchy.

Ex.

<excludeNodesWithWords>

<word>ExpertDiagnostic</word>

...

</excludeNodesWithWords>

Application start-up (continued)The configuration.xml file is thus read upon servlet context initialization and from the information given in this file, the application creates two objects that it stores inside something called a ServletContext attribute (a ServletContext attribute can hold persistent objects which all the servlets can access). The first one is an ArrayList of beamline status objects.

These objects hold everything that we can eventually see on the status page and form a hierarchy of its own. A single BeamlineStatus object holds its name and a list of StatusVariableGroup objects (that were defined in the configuration.xml file nodes inside the beamline node). Each StatusVariableGroup object holds its name and a list of StatusVariable objects that were found within that node. A StatusVariable object holds its name, a corresponding Variable object (that one is extracted from the CALS API and is not eventually turned into the JSON representation - reason for the transient keyword), its last value, timestamp and also the last time that this StatusVariable was updated. All of this for every beamline status node is stored in the servlet context attribute.

The other object stored is the variable hierarchy in a JSON string form. (For more info about JSON aka JavaScript Object Notation https://www.kirupa.com/html5/all_about_json.htm and other easily found resources) We construct this hierarchy and the beamline objects based on the information from the configuration file and store them in the servlet context upon its initialization. This is the reason why the startup can take under 10 minutes of time (we are accessing the API for a LOT of variables, so that later on when servlets make requests, we ONLY fetch the data for a variable and nothing else).

Everything else in the application, meaning the processing of the GET requests is done by the *Servlet classes that take care of the few types of requests we have. For a simple application like this, no proper routing mechanism was implemented. These servlets call upon two static classes, Extractor, which contains functions that directly use the API calls and Processor, which contains functions usually for converting data. Generally, the servlet might get some data as parameters from the GET request, call some Extractor functions to get the data from the API, process it with a function from the Processor static class and the send it back with a GET response. The conversions to JSON representations of objects are handled by the Google GSON library.

All HTTP requests in the application are GET requests, often with some parameters, which specify what we want to fetch from the logging API. Since all the app does is read from the API, transitively from the database, there is no semantic or practical need for POST requests. It also simplifies the application.

Servlet ResponsibilitiesThe ones which only retrieve data to first populate the page dropdown menus on page load (not accessing the API):

VariablesServlet

- this one simply sends in the HTTP response the JSON string of the entire variable hierarchy that we have stored in the ServletContext attribute (the first of the objects stored persistently)

- the JavaScript in the browser then takes this and populates the dropdown menus in the Timeseries and Wirechamber Views of the application (the populateSelect methods of the TimeseriesModule and WirechamberModule in the script.js file)

- runs on every page load

BeamlineServlet

- simply looks at the list of beamline objects stored in the ServletContext attribute (the second of the two objects stored persistently) and makes a list of their names (rather, its JSON representation)

- sends this list in the HTTP response- the JavaScript in the browser then takes this list and populates the dropdown

(populateSelect method of the StatusModule)- runs on every page load

The ones called when we want to fetch information, i.e. when the user clicks submit in one of the three view of the app (either a status page, or a timeseries plot or a wirechamber profile plot):

StatusServlet

- responsible for sending back the proper beamline object filled with last measured values in its variables

- gets the "beamline" parameter from the GET request, finds the respective beamline within the stored beamlines in the ServletContext attribute

- performs the update operation on the beamline, so that the StatusVariable-s within it get filled with new data

- converts this object into its JSON representation- sends the JSON representation as a GET response- is called by the getData() method of the StatusModule, and the display() method takes care

of displaying this data

TimeseriesServlet

- responsible for fetching and sending back the timeseries data for a given variable and interval

- gets the "variable" parameter from the request, as well as the "interval" parameter- uses these to fetch the data from the API (Extractor.fetchTimeseriesData() function)- converts it to the JSON representation and sends as a GET response

WirechamberServlet

- responsible for fetching and sending back the wirechamber profile data for a given wirechamber profile name (and spacing, if present)

- again, fetches the data and converts it to a JSON representation that it then sends back

For specific information about these methods, and the functions of the Extractor and Processor static classes, see the code, the comments, and the JavaDoc.

Front-end overviewThe front-end of the application is a simple combination of HTML, CSS and JavaScript code. The entire app runs in a single index.html page and the three respective views (Status, Timeseries and Wirechamber) are div elements inside this page with a specific hash id. The three tabs on top of the page that are used to switch between these three views are just linking these IDs and the CSS is taking care of showing and hiding the correct view. (For more info: https://www.smashingmagazine.com/2015/12/reimagining-single-page-applications-progressive-enhancement/)

Most of the page is defined before hand inside the HTML file itself, but the contents of the dropdown menus, as well as the info fetched from the database (the actual Status grid, and the actual plots for the Timeseries and Wirechamber Views) are created programmatically inside the JavaScript code and the inserted into a container element (specifically #StatusContainer/#TimeseriesContainer/#WirechamberContainer).

This is done via asynchronous HTTP GET requests (AJAX), thus not needing a page reload.

The JavaScript code has a few dependencies:

- moment.js library for easy manipulation of time (used only for the display of last refresh information in the beamline status page) (http://momentjs.com/)

- plotly.js for easier creating of plots (time series and wire chamber views) (https://plot.ly/javascript/reference/)

- jQuery for easier manipulation of DOM elements (https://jquery.com/)

The script.js file is segmented into the three respective modules with their necessary methods/member variables and a general execution function (the "main" of the JS code) that gets called on successful document load. This (anonymous) function creates some page-wide listeners, initializes the modules and calls their populateSelect methods to prepare the page for user input. For more information, see the script.js file for code and comments.

How to set-up a development environment for the SBA-Beams source codeThe project is a standard Maven project with a few dependencies mentioned above. While the Servlet and GSON API dependencies can be found in the maven central repository, and therefore are automatically downloaded, the CERN proprietary CALS API has to be linked manually. That either means installing it in your local maven repository (https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html) or just putting in the build path of the application.

You can either edit the .java and other files with a normal text editor and then build the app with Maven, which builds the .war that can then be put inside the Tomcat container (be it on your local dev machine or on the server) and tested, but this approach is quite slow.

You can also use the Eclipse IDE and open the project there, link the IDE with a local Tomcat installation you have, which gives you the ability to just save files, and click run on server.

Appendix B: How to use the Java Server Administration Page (“Java Middleware on Demand”)

Administration within the CERN Web Services ManagementUsually websites hosted on the CERN Web Services platform can be configured at their respective Web Services page, like https://webservices.web.cern.ch/webservices/Services/ManageSite/Default.aspx?SiteName=sba-beams for our page.

As is written in the Authoring Information section of the page though , Java MiddleWare On Demand sites are updated and managed through a different web application, to which the link is given (https://mwctl.cern.ch/mwctl/). So for us, the web services page only provides the ability to perform a security scan or deploy web statistics, plus provides some general information about the site.

The Java Middleware on Demand Administration Application

Here we have three “levels of concern”. Sites, containers and applications. The top one is the overview of all the sites (we can make more than one “site”1) which is what we see when we just open the administration application from the link on the previous page.

Clicking on the site name or on the "List Containers" option opens up the second level, which is containers. Containers are wrappers which run our applications and a container can have more than one application. We can also have more containers within one web site. For our purposes though, we only have one site, one container and in it, one web application.

There are no options on the top level of sites, except for the possibility of requesting a new site. Most of the configuration is done in the container level or in the deepest application level.

Container level

Here we can see the State of the container (whether it's running or not, or if it's doing some other operation). This state information is not 100% correct all the time, and sometimes it can show weird or imprecise info - refreshing the page can help.

Within the container view, we have several Actions we can perform.

1 Though I am not sure how this works, and whether it is based on the user, because my other site “test-beams” does not show up here.

Apply Last configuration

- whenever we make any changes to the container configuration, or we upload any files 2 to it (for instance libraries we use with the Manage libraries action, or even if we add security policy files within the application – more on that later) we have to click this button to apply these changes. Afterwards we also have to stop and start the container.

Start

- start the container

Stop

- stop the container

View Properties

- change container-wide properties, e.g. the Java version used, heap usage and command line parameters

- I used this to change the Java version the container uses from 1.7 to 1.8 as well as raised the max heap size to 1024mb

List applications

- brings up all the applications in the container, the deepest level, where we can configure some specifics for an application, explained later on

Show Container Logs

- bring up a list of logs from the container, very often used action, explained later

Monitoring

- show information about heap and thread usage, haven’t used it

Manage key stores

- ability to load custom Key Stores, haven't used it

Manage libraries

upload libraries your application needs

- in our case it's Google's Gson for easy conversion of Java objects into JSON objects (gson-2.7.jar) and the CALS API library (accsoft-cals-extr-client-nodep.jar)

Delete

- deletes the container

2 We don’t have to do this if we deploy a new version of the application (a new .war file).

Container Logs page

Shows several log files that you can either download or show their tail right in the browser.

- gc.log is the logging file for the garbage collector, not something I've used at any point- catalina.log is the logging file for the entire container, this one is helpful because any error

messages from the container are displayed in here- catalina-2016-xx-xx.out is the logging file for our application. Anything we log from our app

shows up here. There is a new one every day.

(Catalina is the name of the actual servlet container within Apache Tomcat, which is comprised of several other components)

Application Level

State - here we see if the app is running or not - we can stop it but let the container run

Actions in the Application View:Start/Stop

- start or stop running the application

View Properties

- here we can deploy the actual .war files for the application, as well as configure the authentication/authorization options, explained later

Manage Permanent Storage

- show existing/request new permanent storage which the app will have access to- I used this to request a folder on AFS to host the configuration.xml file. This folder is

accessible from within the app, and it reads the file on start-up and uses it to populate the beamline objects with variable names, get the top-level nodes in the variable hierarchy to collect variables from (in our case its SPS-EA and EAST-HALL) and also get the list of words any nodes we want to exclude may contain.

Undeploy

- undeploy the app but keep in the container

Delete

- delete the app completely

Download Last Deployed

- download last deployed .war

Move

- move to a different container

Manage Security

- here we can add .policy files which alter the security configuration of the container- we are using a beams.policy file to grant the app access to a server property which the

logging service library needs to set and then read

Manage Runtime options

- same thing like the last one, but for runtime options, not used for anything in our application

View Properties Page

- here the service keeps maximum of three last deployed versions of the application, I always tend to keep the first one that was there upon creation (default.war) to have a fallback working example of an application when something goes wrong (it just contains a few examples of websites)

- when I upload a new version, I usually delete the pre-last version, which is not deployed anymore, and then using the Upload button, upload the new .war. When this processes, the app is starting and there is no need to do anything else. I always check the logs to see if all the messages I log at start-up are appearing and whether are any errors to be seen.

- in the Authentication Manager tab I have disabled the SSO Authentication, which removes the necessity of logging in with CERN credentials when someone uses the site

- any changes in the Authentication/Authorization Manager tabs need the "Apply Last Configuration" action in the container executed and then have the container restarted

In case of any questions, or problems there is this Help Page https://information-technology.web.cern.ch/services/java-web-hosting with some How-Tos and FAQs. For anything else I recommend contacting the service desk using the “Submit a general request” button on that page. I found that the people maintaining these sites are very helpful and friendly, even if the system has its kinks.

WorkflowsEditing the configuration.xml file

1. The XML file path in it’s full version is "/afs/cern.ch/project/jps/reps/sba-beams/configuration.xml"Though if you are using OpenAFS on Windows for instance, it gets mounted to a drive, in my case, on my computer it is “H:\project\jps\reps\sba-beams\configuration.xml.

2. Edit and save the file as needed.3. Use the Stop/Start buttons on the Container level to restart the container. Note: Always wait

until the container is completely stopped (NOT_RUNNING in the State field instead of STOPPING) before Start-ing it again. The start-up will take several minutes, should definitely be under 10. When you start the container, check the catalina.log log file for any error and after a few seconds, the catalina-2016-xx-xx.out log file for our logs which are displayed as we populate the variables in our app. You can always refresh the logs by clicking the Refresh button in the top right corner.

Deploying a new version of the application1. Open the View Properties window for the application

2. Optionally, you can delete one of the old versions of the application – I prefer to leave the default.war always there in case I need to test whether a problem is caused by my application or if it’s a problem on the container end. That leaves two versions of my application, one that is deployed, and the one that was deployed before that. I usually delete the one that was deployed before.

3. Click on the Upload button and find the .war file.4. The new version is deployed automatically, no need to restart anything.5. Check the logs for any errors and for our logs indicating the app is starting up.

Appendix C: Important links summaryThe link to the web application:https://cern.ch/sba-beams

Location of the configuration.xml file:

/afs/cern.ch/project/jps/reps/sba-beams/

The web application home in the CERN Web Services administration: https://webservices.web.cern.ch/webservices/Services/ManageSite/default.aspx?SiteName=sba-beams

The web application administration page within the Java Middleware on Demand service:

https://mwctl.cern.ch/mwctl/zul_pages/applications/index.zul?containerId=448&siteId=456

Logs for the web application container within the Java Middleware on Demand service:https://mwctl.cern.ch/mwctl/zul_pages/logs/index.zul?containerId=448&siteId=456

Information about the CALS API: https://wikis.cern.ch/pages/viewpage.action?pageId=54067820#DataExtractionAPI/TIMBER-ProgramaticDataExtraction

JavaDoc for the CALS API (client):

http://abwww.cern.ch/ap/dist/accsoft/cals/accsoft-cals-extr-client/PRO/build/docs/api/

JavaDoc for the CALS API (domain):

http://abwww.cern.ch/ap/dist/accsoft/cals/accsoft-cals-extr-domain/PRO/build/docs/api/