FUJ00176533 - Email from Paul Gauntlett to Gerald Barnes RE: Summary of Riposte and HNGx

Evidence on official site

FUJ00176533
FUJ00176533

From: Gauntlett, Paul[/o=ExchangeLabs/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=20fad69c 1 be54161 9bbf58bbefdae198-Gauntlett,]

Sent: Tue 30/11/2021 5:17:46 PM (UTC)

To: Barnes, Gerald”

Subject: RE: Summary of Riposte and HNGx

Hi Gerald - this looks really good and concise thanks.

tho atm so will reread in the mornin, ind let you know if I have any

comments

From: Barnes, Gerald I.
Sent: Tuesday, November 30, 2021 5:10 PM
To: Gauntlett, Paul <7
Subject: Summary of Riposte and HNGx

Hi Paul,

1. Originally a system called Riposte was used to gather audit transactions from all the Post Office counters. It
was a big distributed database.

2. There were two data centres. Each evening all transactions were harvested and put in files. Different files
were produced in each data centre but they each contained the same transactions all be it in a different order
and for different FADs.

3. One audit server gathered one file and the other the other. Although there was an option to robocopy files
from one to other it was switched off for these files because there was already two copies of each transaction.
4. Around 2010 the contract for looking after Post Office transactions came up for renewal. Fujitsu’s proposal
was a rewrite called HNGx which eliminated Riposte (for which there was a big annual licence fee). As a part of
this rewrite all transactions were stored in one file only.

5. The auditing of these files was done by one audit server only and what it stored each evening was
robocopied and stored on the other audit server.

6. Once all Post Office counters were converted to HNGx as a tidying up exercise the audit configuration files
were changed such that only IRE11 actively gathered and all files that were stored were robocopied to IRE19
each evening.

7. When ARQ requests for a FAD code are made all relevant files are got back from the audit server being used
(they may have been robocopied, they may be gathered directly). Then they are processed by the Query
Manager service on the audit server. Now whether Horizon or HNGx each transaction has a unique number
associated with it. The Query Manager checks that the transactions have not been tampered with and also
checks whether or not there are any duplicates or gaps in the sequence of transactions.

8. It is very rarely the case that there are gaps in the Horizon transactions on one audit server but not the other.
9. These gaps are caused by the rare malfunction of the Harvester process on one data centre.

10. I went through PEAKs yesterday using a free text search and found one such instance reported. I looked in
detail at that. Now Horizon nodes have two sorts — counter transactions which are nodes 1-32(or maybe 31) and
some sort of administrative correspondence server nodes which have a bigger number. The gaps were in the
correspondence server nodes only. There is good reason for that. In Riposte all transactions have a build in
retain time and it is more for real transactions than correspondence server transactions. So if the harvester is
down for a period it is more likely that the correspondence server transactions disappear than the real ones. So
maybe the harvester was down for some reason or other and by the time it got going again the correspondence
server transactions had disappeared.

Regards,
Gerald Barnes
Gerald Barnes
Senior Software Engineer
Post Office Account

Fujitsu
Lovelace Road, Bracknell, Berks, RG12 8SN

Linked in: http:www.linkedin.com/in/GeraldJamesBarnes
Web: http://uk.fujitsu.com

© £I¥inIe)

Si

© Fujitsu named as
Responsible Business
of the Year

Fujitsu is proud to partner with Action for Children
I-ClO: Global Intelligence for the ClO. Fujitsu's online resource for ICT leaders
Sponsors of the 2015 Rugby World Cup

Please consider the environment - do you really need to print this email?

FUJ00176533
FUJ00176533