FUJ00173184 - Peak Incident Management System Log PC0280793 - Audit Data extract filtering failing for July 2015
FUJ00173184
FUJ00173184
Peak Incident Management System
Call Reference PC0280793 Call Logger Gerald Barnes -- Audit-Dev
Release Reported In -- HNG-X Rel. Ind. Top Ref PC0280466
Call Type Cloned call Priority B -- Progress stopped
Contact Gerald Barnes Call Status Closed -- Advice and guidance given
Target Date —_No Forcast Effort (Man Days) 0
Summary Audit Data extract filtering failing for July 2015
Iny
Seca cae bee
Gerald Barnes 23-Oct-2019 14:35:04
Having all the events gathered together in a lump makes things very difficult for the prosecution team. What
it means is that any query for which there are days with no events must include the catch-up lump day.
Progress Narrative
foate:23-Oct-2019 14:25:06 User:Gerald Barnes
CALL PC0280793 opened
Jbetails entered are:-
lsummary:Audit Data extract filtering failing for duly 2015
call Type:c
call Priority:B
target. Release:HNG-X Rel. Ind.
Routed to:Audit-Dev - Gerald Barnes
Date:04-Oct-2019 14:10:34 User:Farzin Denbali
ALL PCO280466 opened
Details entered are:~
Sunmary:Audit Data extract filtering failing for July 2015
call Type:t,
call Priority:B
target Release: HNG-X Rel. Ind.
Routed to:PODG-Dev = Gerald Barnes
jDate:04-Oct-2019 14:10:34 User:Farzin Denba:
[the Audit Data extract for July 01 to July 14 2015 fails with ‘Filtering Failed’ message. Perl Error log shows:
fhe supplied date Tue Jul 14 23:59:59 2015
dinus the largest message date found 20150706 is greater than 1. Files need to be extracted with a bigger upper date.
It ran the ARQ for 2 branches and the result was the same. When ARQ is run for the entire month the query completes and the gaps
lin the Events data is visible. The Events spreadsheet shows there are no events between July 3 and July 10 (see attached) but
there is transaction data between those dates.
jbate:04-Oct-2019 14:11:14 Uscr:Farzin Denbali
evidence Added - Perl Error
jDate:04-Oct-2019 14:11:28 Uscr:Farzin Denbali
evidence Added ~ Events
JDate:04-Oct-2019 14:17:24 User:Jason Muir
the Call record has been transferred to the team: Audit-Dev
[fhe Call record has been assigned to the Team Member: Gerald Barnes
Date:04-Oct-2019 16:51:57 User:Gerald Barnes
[Start of Response]
It gathered the event data EVENTS EDS1 from 1st July 2015 to 31st August 2015 and then the problem became clearer.
It attach the spread sheet "Date Gathered” which illustrates the problem.
[tt has a column “Date Gathered". None are gathered from 7th July to 21st July but on the 22nd July you can see all the missing
event files, all of which are much bigger than usual.
{End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
liours spent since call received: 2 hours
jbate:04-Oct-2019 16:54:37 Uscr:Gerald Barnes
FUJ00173184
FUJ00173184
[Date:23-Oct-2019 14:25:06 Uscr:Gerald Barnes
call cloned from original call:PC0280466 by User:Gerald Barnes
Date:23-Oct-2019 14:31:07 User:Gerald Barnes
[start of Response]
It shall keep the original PEAK on the audit-dev stack for considering what to do about this issue from an audit point of view.
However something has definitely gone wrong with the event generation. There were no events to be gathered from 7th July to 21st
\fuly 2015 but then lots were gathered on 22nd.
[End of Response]
Response code to call type C as Category 40 -- Pending -- Incident Under Investigation
Hours spent since call received: 1 hours
Date:23-Oct-2019 14:35:04 Uscr:Gerald Barnes
new Business Impact has been adde
liaving all the events gathered together in a lump makes things very difficult for the pros.
luuery for which there are days with no events must include the catch-up lump day.
cution team. What it means is that any
[Date:23-Oct-2019 1.
[Start of Response]
2 well as knowing what has gone on from an audit perspective we need to know whether this has ever happened before.
[End of Response]
Response code to call type C as Category 40 ~- Pending -- Incident Under Investigation
8:05 Uscr:Gerald Barnes
[Date:23-Oct-2019 14:38:41 Uscr:Gerald Barnes
the Call record has been transferred to the team: Tivoli-Dev
Date:24-Oct-2019 15:35:06 Uscr:Shaun Wood
[the Call record has been assigned to the Team Member: Pete Flannery
bate:24-Oct-2019 1
jfarget Date/Time update
[Start of Response]
Passed to Pete for investigation.
{End of Response]
esponse code to call type C as Category 40 -- Pending -- Incident Under Investigation
5:24 Uscr:Shaun Wood
new value is 31/12/9999 00:00
JDate:04-Nov-2019 16:38:03 Uscr:Pete Flannery
Ir think the problem is down to the fact that the design is such that the product relies on a high water mark as the basis for
selecting the latest set of records. If the service has been down for any time, for whatever reason, then there will be a larger
set of records to retrieve and hence a larger file size will occur.
the script runs continuously as a service. It has a built in delay of an hour. Any modification would therefore require a design
change.
oate:06-Nov-2019 16:02:12 User:Pete Flannery
{Start of Response]
This issue goes back to 2015. We are not aware of any other, more recent service/monitoring issues.
s previously suggested any improvements would therefore require a design change.
[End of Response]
lkesponse code to call type C as Category 94
outing to Call Logger following Final Progress update.
lbefect cause updated to 7 -- Design - High Level Design
Final -- Advice and guidance given
JDate:06-Nov-2019 16:04:23 Uscr:Gerald Barnes
CALL PCO280793 closed: Category 94 Type C
Root Cause Design - High Level Design
Logger Gerald Barnes -- Audit-Dev
Subject Product General/Other/Misc -- Unknown (version unspecified)
Assignee Gerald Barnes -- Audit-Dev
Last Progress 06-Nov-2019 16:04 -- Gerald Barnes