Noctam/DWP/ACS Test Harness/Notes - Revision history

Stuart: /* NPS Handling */

2021-09-09T13:46:28Z

NPS Handling

← Older revision		Revision as of 13:46, 9 September 2021
Line 62:		Line 62:

	=== NPS Handling ===		=== NPS Handling ===
	NPS ~~has stumped me a bit because~~ I have no ~~example calls~~, so I can~~'t even guess~~ at ~~how~~ it's ~~used from~~ the ~~client side yet~~. ~~There are~~ a ~~few references~~ to ~~NPS in~~ the ~~code~~, ~~but no obvious~~ {{c\|~~httpd~~.~~serve_forever~~()}} ~~call specifically for NPS.~~ {{c\|~~pdserve.py~~}} or {{c\|~~pserved~~.py}} ~~are my best guess at how~~ it's ~~run~~, ~~but that~~ is ~~just~~ a guess.		So, after I got some more input, apparently the server script being used is {{c\|pdservep.py}}.
			I've gone through that to try and get a handle on NPS - I ''still'' have no idea how it's called (i.e. what headers or content I should use), but I can break down the processing that occurs at least. It should be fairly simple, from what everyone seems to say... so...

			* To recognise an NPS call, the server looks at the path of the http request, specifically, it looks for {{c\|paths.NPS_PATH}} which resolves to {{c\|http://enirswebservices/JobcentrePlus/JobcentrePlus.asmx}}. So this is suspect in a number of ways:
			** Well, that's not a path - that's the entire URL; the other paths are just request paths, eg. {{c\|/IB_CIS_VME_WEB/base64}} or {{c\|/cis_webservices_r2/services/CorporateCISDCI908NameTraceWS03}}.
			** Also, {{c\|http}} and not {{c\|https}}?
			* So, yeah - No idea what's going on with that.
			* For a recognised NPS path, it hardcodes the 'qtype' and 'dialog' to {{c\|NPS_R_RQST}} and {{c\|NPSR}}, respectively.
			* It validates the headers, erroring immediately if any unexpected values are found. It expects the following:
			** {{c\|Accept-Encoding: gzip}}
			** {{c\|Connection: Keep-Alive}}
			** {{c\|Host: enirswebservices}}
			** {{c\|Proxy-Connection: Keep-Alive}}
			** {{c\|SoapAction: http://enirs2.nirs2.gpn.gov.uk/webservices/BF35083_RetrieveCISData}}
			** {{c\|Content-Type: text/xml; charset{{=}}utf-8}}
			* It validates that there is no whitespace in the SOAP message (?!)
			* It uses the above hardcoded qtype value (which, in the called method is called 'dialog' - not at all confusing) to return {{c\|query}} and {{c\|operatorid}} of {{c\|"nino{{=}}x"}} and {{c\|Nothing}}, respectively; the {{c\|x}} in the former being the NINO from the submitted XML.
			* It creates a compound query from the query and dialog for the config file it's running with, something like: "NPSR;nino=AA111111A;"
			* After using the above query to find the response file, it compresses it (with {{c\|zlib.MAX_WBITS{{!}}16}} - i.e. including a gzip header in the output, apparently)
			* After that, it returns the output and exits. There is no replacement handling in this particular program, so it is a bit simpler.

			==== Notes ====
			So, this is the hackiest yet, really - probably the simplest, but there's an awful lot of hardcoding some stuff but not others, some ropey naming of local variables, destined to confuse (dialog meaning different things at different call levels). And I have no idea which config you would use with this and have no example input content.

			Ultimately, this is all still a bit vague - I've basically overspecified what the code does (the above is practically code level) to try and make up for it. I'll have to come back to it really.

			I ''do'' think this all could be done, fairly easily, with the same program rather than having two separate ones - it specifically uses the path of the HTTP call to determine whether to active 'NPS' handling over DCI (or other, I guess). I might try and combine them, though that would be risky without actually being able to test them properly.

Stuart: /* NPS Handling */ A more detailed shrug

2021-09-08T09:59:21Z

NPS Handling: A more detailed shrug

← Older revision		Revision as of 09:59, 8 September 2021
Line 62:		Line 62:

	=== NPS Handling ===		=== NPS Handling ===
	~~No idea.~~ I ~~don~~'t even ~~know~~ how it's ~~kicked off or~~ used from the client-side.		NPS has stumped me a bit because I have no example calls, so I can't even guess at how it's used from the client side yet. There are a few references to NPS in the code, but no obvious {{c\|httpd.serve_forever()}} call specifically for NPS. {{c\|pdserve.py}} or {{c\|pserved.py}} are my best guess at how it's run, but that is just a guess.

Stuart: Up to dating.

2021-09-08T09:54:53Z

Up to dating.

@@ Line 5: / Line 5: @@
 == CISSIM ==
 * Reads config provided
 * 'FOLDER' is the folder in which the output files are stored
@@ Line 20: / Line 27: @@
 * Finally, it stringifies the XML document object it's been playing with, outputs it (interestingly, using chunked encoding) and goes about its business.
-=== Some observations ===
+==== Some observations ====
-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.
+OK, this is actually quite flexible, and, although the code is terse and largely 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.

Stuart: Notes on DCI calls to CISSIM

2021-09-07T16:41:44Z

Notes on DCI calls to CISSIM

@@ Line 13: / Line 13: @@
 *** {{c|DCI923_R_RPLY}}
 ** And the 'system id' from the {{c|ns1:systemID}} value of the provided XML.
-* It then uses those values to look up entries in the config for that type of call; the entry is a dict with 'output file name' as key, and a list of key/value pairs... which I'm getting to.
+* It then uses those values to look up entries in the config for that type of call; the entry is a tuple made up of:

Stuart: Save my work

2021-09-07T16:08:56Z

Save my work

New page

{{Nav/ACS Test Harness}}
= Notes =
Just a scratchpad to make notes as I'm looking at stuff.
Temp stuff - probably be wiped regularly.

== CISSIM ==
* Reads config provided
* 'FOLDER' is the folder in which the output files are stored
* Handling for DCI calls puts together a lookup key from:
** The 'dialog' - one of:
*** {{c|DCI908_R_RPLY}}
*** {{c|DCI913_R_RPLY}}
*** {{c|DCI923_R_RPLY}}
** And the 'system id' from the {{c|ns1:systemID}} value of the provided XML.
* It then uses those values to look up entries in the config for that type of call; the entry is a dict with 'output file name' as key, and a list of key/value pairs... which I'm getting to.