Noctam/DWP/ACS Test Harness/Diary/Week 1

From The Dreaming
Jump to navigation Jump to search
ACS Test Harness

Meetings

Existing System

Specifications

Diary
2009:

Notes

Day 1: 06/06/2021

Initial workshop to discuss requirements and broad development strategy. See Meetings: Initial Workshop.

Day 2: 07/09/2021

In which I:

  • installed and set up intellij + python on my noctam PC
  • created simplistic sim-start and sim-stop scripts to start and stop the CISSIM server
  • got it up and running, which required a bit of jiggery-pokery:
    • needed to install windows-curses in my python environment: pip install windows-curses
    • Fixed a couple of relative paths hardcoded into a couple of python files. To wit:
 commit 5205c969edcfe9e075ca8261a3ca2f13fa3e7129
 Author: Stuart Wood (Noctam) <stuart.wood@noctam.co.uk>
 Date:   Tue Sep 7 14:34:42 2021 +0100
   
   Don't rely on relative paths for files/folders
   
   Adds a 'getrootfolder' function to pdutils which gets the root folder of
   the 'project', by getting the parent of the directory in which the
   pdutils file is found.
   
   I can't immediately think of any problem with this, and it means you can
   run it safely from anywhere.
   
   This also dynamically alters the 'FOLDERS' config value (actually it
   checks of the config value starts with '../' and replaces '../' with the
   root folder provided by getrootfolder()) when it loads the config.
  • Stepped it through a DCI913 call to get an idea of a) what it did, and b) how it did it. My notes are available, for now, but in a nutshell:

OK, this is actually quite flexible, and, although the code is terse and uncommented, it's not that hard to follow. Ultimately, it doesn't do that much (in the above, quite narrow, use case) - I could fairly easily strip out everything that isn't required by a DCI call and just have that as our starting block of code... I might do that, though I want to get PDD and NPS in there too, neither of which are handled in my initial examination above.

Day 3: 08/09/2021

Plan

  • Step through PDD processing in the CISSIM program
  • Step through NPS processing too
  • Document the aboves
  • Start stripping out unused files / classes and reduce the program to its minimum codeset for ACS testing
  • Start a design of the java version of it
    • I'll probably need to talk through some aspects of it (inputs / outputs) with the FDACS team, maybe tomorrow for that.

Execution

  • Well, I stepped through the PDD processing
  • I identified a few things which will need looking into - see Notes/CISSIM - the config processing is probably the main one since it's needed for PDD and it does some pretty meaty stuff at config loading time to determine the locations for the fields within PDD data blocks.
  • I picked up some new setup instructions, which included reference to scripts that Sean has written to start and stop the servers - plural, i.e. the NPS server as well. Duh.
  • Looked through NPS - looks really straightforward - doesn't really do that much as far as I can tell. I'll look at it more in a bit, because...
  • I decided to take a half day, because I'm really feeling like I need the real stuff rather than the piecemeal bits that I'm looking at here. Gives me chance to catch up on some home chores too.

Plans for tomorrow

  • Look through NPS and document it properly.
  • Modify the scripts to start and stop the NPS Sim server too
  • Really dive into the config to see what it does - more concerned with the PDD side of things than DCI / NPS
  • Start stripping away the stuff that we don't immediately need for ACS Test Harness
  • Broad design for the java CIS Sim server, with respect to ACS dev testing

Day 4: 09/09/2021

  • So, I got all of this up and running on Linux too - actually makes the terminal and python run much smoother - it's kinda built for that sort of environment.
  • I did an analysis of the two server files and deleted (pretty much) everything which they don't use. Quite a bit easier to see what's there now.
  • I also analysed NPS as much as I could without a valid config to use or example client calls. This is available at Notes/NPS Handling

The rest of the day

I want to start designing really, so I'm going to spend some time with pen and paper to see what I can come up with in the next couple of hours.

Day 5: 10/09/2021

Reflections on yesterday

So the design that I put together yesterday was a bit... well, "simplistic", I guess.

Server -> URLMatcher -> TxnTypeHandler -> Validator -> ...
                        |- DCIHandler     |- HeaderValidator
                        |- PDDHandler     |- ContentValidator
                        |- NPSHandler     |- OtherThingsValidator

No real notion of how to configure all of this... and, if I'm honest, still no real notion of what we will be testing.

"Given input X, ensure output of Y"

To be honest, this won't be doing much testing work itself beyond:

  • Is ACS using certs correctly?
  • Is ACS sending correct header values
  • Is ACS sending appropriate content

So, we need to ensure that we can configure:

  • Certs to use
  • Header checks against... what? URL?
  • Content checks, and how to take what's given and reflect it back in the response.

To be honest, for all the hackiness of Mark's code, it's pretty solid and does the job. Once you trim away all the unnecessaries, you could strip it down to quite a simple few program files and wrap a couple of bash scripts around it to do the dirty work.


So the real benefit that I will be adding, I think, isn't the java version of CISSIM, but the containerised images. I think I can define a network within the docker containers which will allow us to use the runtime hostnames / URLs, so we can run ACS as close to a real deployment as possible.

Reflections on today

OK, so I've implemented a first draft of a java-based server. See the JCIS Test on Gitlab. It's really really basic - just a proof of concept of an HTTPS server which uses PEM files, really.

Most of the heavy lifting is done by the SSL Context Kickstart library - it makes it pretty easy to generate an SSLContext using PEM files for keys and certificates.

The rest is the very simplistic HttpsServer provided in java. I don't think this will be the solution going forward; I just wanted a very straightforward implementation that I could get up and running without a load of boilerplate or 'magic code' so I could concentrate on getting the PEM handling working.

Next steps

So, there's quite a bit to do, really.

  • Clean it up - the code's a disgrace ("listenAndTing", really?)
  • Fully implement the handler for DCI908, and, in so doing, introduce a semi-sensible architecture for handling HTTP calls
  • Implement DCI913 and DCI923 in the same way
  • Using (possibly extending) the above mechanism, implement PDD and NPS
  • Separate the handling from the server implementation - as little hardwiring as possible
  • Implement using a different server implementation - a spring boot one perhaps - wrapping jetty or tomcat

The above will probably take me at least a week to nail it. But we should be in a pretty good place by the end of it - with a test server more or less there, and we can start expanding it to cover all the test cases we need.