galatea-associates / fuse-starter-java

Starter project for Galatea java projects
17 stars 73 forks source link

fuse-starter-java

This project serves two functions:

Fuse is designed primarily to mock a securities settlement service, along with some other smaller service components.

Settlements involve processing a trade request, and spawning relevant 'missions' that interact with various agents and counterparties to handle the delivery and receipt of securities and cash.

This readme will contain an index to features and their location in code.

Getting Started

Java

Maven

Git

This will create a new project in Intellij and download a copy of this project into it.

Git Clone to Eclipse
  1. Open Eclipse.
  2. "File" -> "Import" -> "Git" -> "Projects from Git"
  3. Click "Next", select "Clone URI" and then click "Next" again.
  4. In your browser of choice go this project's page
  5. Towards the top of the page click the drop down with the text "Code"
  6. Copy the URL in the text box under "HTTPS"
  7. Back in Eclipse, past the URL you copied into the "URI" field.
  8. At the bottom of the window enter your gitlab username and password.
  9. Click "Next" three more times until you have the option to select "Import as General Project".
  10. Click "Finish"

This will create a new project in Eclipse and download a copy of this project into it.

Eclipse

IntelliJ

A note on spring profiles

Maven

Postman

Branching model

We use this branching model in fuse-starter-java: http://nvie.com/posts/a-successful-git-branching-model/

SonarQube integration

Components

FUSE suggests that you break up your application into the following components. Many of these correspond to spring stereotypes:

Dev best practices

JMS

FUSE currently shows how to read from a queue (not a topic).

org.galatea.starter.entrypoint.SettlementJmsListener - shows how you listen for messages. Supports both JSON and Protobuf message formats. org.galatea.starter.utils.jms.FuseJmsListenerContainerFactory - provides a custom "listener container" factory (which is a spring jms concept). We use our own factory, so we can create our own "listener container". org.galatea.starter.utils.jms.FuseMessageListenerContainer - is a custom listener container. This is the code that will actually call the JMS listener that you have registered. You'll notice that we populate our trace repository here. This allows us to capture every message we process and the resulting outcome.
org.galatea.starter.JmsConfig - is the spring java config related to jms org.galatea.starter.entrypoint.SettlementJmsListenerTest - shows you how to test a jms listener. SpringBoot fires up an embedded ActiveMQ broker for the test. It's important to look at the mentiod annotated with @After in ASpringTest. You'll see that we tear down the jms connection after each test to ensure isolation between tests. This is important.

JPA

Logging

Request Audit

For inclusion of audit details in the response headers see: FuseWebRequestTraceFilter.addAuditHeaders()

Testing

This section will cover some high level principles that we want to follow. Specifics about testing a feature (e.g. JMS) will be covered in the section relevant to that topic.

Automated testing is good. You should do it. You should also design your application to be easily tested. It's important to think about testing "seams" up front. Designing for testability is just as important as designing for functional or performance requirements.

We often struggle with the terms unit vs integration test. For the purposes of FUSE, let's define as follows:

To run the FUSE unit tests:

Mocking is a good way to unit test (keeping in mind that your mock needs to be used in conjuction with a integration test). FUSE has plenty of examples of how to use @MockBean. See org.galatea.starter.entrypoint.SettlementJmsListenerTest and org.galatea.starter.entrypoint.SettlementRestControllerTest for some examples of how to mock. Both of those tests mock out the settlement service using given(...) or verify(...)

For testing rest requests/responses see:

Builds

We have a Jenkins server hosted on AWS that handles the FUSE continuous integration process - https://jenkins.fuse.galatea-associates.com

The build process is handled via a Jenkins pipeline build, with the pipeline managed via the Jenkins file in the root of the project. We recommend that all of your build steps are captured in the Jeninks file. You should not define any build steps directly within the Jenkins server.

We currently don't have a recommendation for how to handle this in TeamCity and would love someone who is familiar with TeamCity to recommend an equivalent model.

Application and Thread Monitoring

In order to view the status of a running FUSE application you can use VisualVM. Downloads and installation instructions are available at https://visualvm.github.io/download.html. Basic Instructions

Using VisualVM Once the application is opened in VisualVM there are several tabs filled with different information about the application