POL00001265
POL00001265
Peak Incident Management System
Reported In -- BI_3S90R KEL CObeng2634M.
B -- Business restricted
tion
—
‘Date:27-Mar-2006 11:40:38
(CALL PC0133933 opened
‘Details entered are:-
iSummary:Branch 101801 - TPSC254 Harvester Exception
call Typ
call priority:B
Marget Release:BI_3890R
U-Indt Mgt - Pooja Sujith
iser:Pooja Sujith
bate:27-Maz-2006 11:40:38 User:Pooja sujith
isc254 - Harvester Exception report. Produced on 24/03/2006.
Whe branch shows 1 new harvester exception.
[Error message reads: ‘Could not update database: Updating table TD
Qt
Whe 'Mode' field is blank.
RX_EPOSS_TRANSACTIONS, ORA-01400: cannot insert
ULL into
Relevant reports attached. KEL CObeng2634M is relevar
‘Date:27-Mar-2006 11:40:44 Usor:Pooja Sujith
‘Date:27-Mar-2006 11:40:50 User:Pooja Sujith
evidence Added - TPSC257_24/03/06
‘Date:27-Mar-2006 11:40:55 User:Pooja Sujith
Bvidence Added - 7280250 24/93/06
‘Date :27-Mar-2006 11:42:08 Uscr:Pooja Sujith
IOCR PSujith4146L has been raised. Sending to EDSC for investigation.
a
pate:27-Mar-2006 11:42:29
‘Date:27-Mar-2006 12:06:01 User:Lorraine Elliott
ine Call record has been assigned to the Team Member: A
© Chambers
Date:27-Mar-2006 12:56:03 Use
JOCR PSujith41461 approved
Date:27-Mar-2006 16:12:36 User:Anne Chambers
[[start of Response]
4 have repaired the problem transaction and will check tomorrow that it has been sent ok.
[As far as I can tell, no call has gone to development about this. To summarise,
- Some messages get written with a null Mode attribute. The root cause of this has never been resolved.
@ harvester agents so that me:
When Mode is missing (it assumes SC).
ages with <It
Name:Mails> or <Applicatio!
ails> can be handled
- MailsBalance messages have <Applications:Mails>, not <Application:Mails>. This was spotted soon after their introdu
January, and I did intend to raise a Peak, but don't seem to have done so. At the time it was thought to be benign
ion in
MailsBalance messages with missing Mode are now
as to be repaired individually.
g a number of harvester exceptions (5 on the reports for 24/3). Each
{So we need to sort out the <Applications:Mails> issue
ican be fixed fairly soon in
fis basically a typo.
nis could be fixed either at the agent, or in the Mails scripts. If it
he scripts, I think that would be the better option, rather than making the agent cope with what
I@here are example messages in the attached reports, or I can provide a messagestore if r
quired. Routing to Mails Dev
F/338/1
(probably Richard O'Neill) via QFP.
[lend of Response]
Response code to call type
as Category 40
eived: 0 hours
Pending -- Incident Under Investiga’
;
jaco:27-Mar-2006 16:12:55 “Iser:Anne Chambers
‘Date:27-Mar-2006 16:16:28 Uscr:Anne Chambers
The Call record has been transferred to the team: QFP
‘Date:28-Mar-2006 13:26:34 User:Peter Ambrose
Whe Call record has been assigned to the Team Member: Mark Scardifield
‘Date:30-Mar-2006 18:46:34 Uscr:Mark Scardifield
[Is this a duplicate of PC0131323?
‘Date:30-Mar-2006 18:46:46 User:Mark Scardifield
ihe Call record has been transferred to the team: APS-Ctr-Dev
‘Date:30-Mar-2006 18:46:56 User:Mark Scardifield
‘The Call record has been transferred to the team: APS-Ctr-Dev
Date:31-Max-2006 09:52:37 User:Adrian Goodwin
Whe Call record has been assigned to the Team Member: Adrian Goodwin
Date:31-Mar-2006 11:08:47 User:Adrian Goodwin
This PEAK refers to the problem of Mails messages being generated with <Applicatio
eventing a harvester agent circumvention for a null Modes problem from working.
he subject of PBAK PC0131323 and PBAK PCO134069 and appropriate clearances will b
itherefore not be considered here.
Th:
the real problem identified in this PEAK is the missing Mode attribute value.
laffect Mails messages. The Mode attribute is added to messages by Escher when
written to the message store by RetailBroker.
PEAK should therefore be transfered to Escher-Dev so this PEAK is b
Date:31-Mar-2006 11:09:06 User:Adrian Goodwin
ne Call record has been transferred to the team: QFP
is
03-Apr-2006 07:27:41 User:Lionel Higman
Call record has been assigned to the Team Member: Mark Scardifield
he
i
jate:06-Apr-2006 10:58:15 User:Mark Scardifield
whe Call record has been transferred to the team:
Escher-Dev
‘Date:06-Apr-2006 14:07:31 User:Mike Coon
[Start of Response]
the messages are added to the transaction stack /
POL00001265
POL00001265
ns:Mails> attributes and how this is
The <Applications:Mails> attribute problem is
@ supplied against those PEAKs and should
is a well known problem and does not ju
eing routed to QFP for their consideration.
This may be a "well known problem" but this does no mean that it is worth chucking over the fence to Escher!
need to give them a reasonably high-probability scenario in which the problem arises. If it is only in a tiny fractional
percentage of daily transactions then they can hardly be expected to investigate it with no further evidence.
areth Jenkins confirms that this logic has been applied all along
[End of Response]
Response code to call type L as Category 36 -
jours spent since call received: 0 hours
Pe!
ding -- Known Problem Registered
:
‘Date:06-Apr-2006 14:08:08 User:Mike Coon
iThe Call record has been assigned to the Team Member: Parked
‘Date:08-Jun-2007 15:34:34 User:Mark Scardifield
nother one that I am going to route to RMF to consider closing. There may well be a bug in Escher
jhave a reproducible scenario that we can take to them (2) any resulting fix will be to a component
Meg RetailBroker)
:
code but
that we do not wish to take
(1) we don't even
2
ate:08-Jun-2007 15:34:46 Usor:Mark Scardifield
F/338/2
ihe Call record has been transferred to the team: RelMngmntForum
Spave:14-gun-2007 15:36:48 doer: Tysone Cozens
Routing for attention of Mark Scardifield at Esher Dev. RMF have decided that tl
is Peak to this effect.
‘Date:14-gun-2007 15:37:10 User: Tyrone Cozens
jhe Call record has been transferred to the team: Escher-Dev
Date:14-Jun-2007 15:51:56 User:Mike Coon
jhe Call record has been assigned to the Team Member: Mark Scardifield
Date: 15-Jun-2007 11:43:16 User:Mark Scardifield
[Start of Response]
[It was agreed at RMF that this PEAK could be closed.
© summarise, a workaround has already been implemented in the TPS Harvester to insert m
(aka mails) scripts have also been modified so that Mails Balancing messages are also caught by this workaround.
Whis PEAK remains to investigate and possibly fix the underlying cause. For the reasons given above and the limited
jexpectancy of the Horizon counter it was agreed that this would not be cost effective and hence this PEAK should be
[End of Response]
Response code to call type L as Category 70 -- Final -- Avoidance Action Supplied
outing to Call Logger following Final Progress update.
Date:18-Jun-2007 10:22:13 User:Pooja Sujith
[Start of Response]
outing call to Anne to see response from Mark.
[End of Response]
Response code to call type L as Category 40 ~
- Incident Under Investigation
‘Date:18-Jun-2007 10:22:20 User:Pooja Sujith
ihe Call record has been transferred 2 team: EDSC
{Date:18-Jun-2007 10:56:13 User:Lorraine Elliott
Whe Call record has been assigned to the Team Member: Anne Chambers
‘Date:18-Jun-2007 13:54:33 User:Anne Chambers
[Start of Response]
sponse noted. I never really expected the root cause to be investigated or fixed. The typo which caused the agent
ircumvention to fail was fixed a long time ago. Closing call.
[End of Response]
esponse code to call type L as Category 70 -- Final -- Avoidance Action Supplied
Routing to Call Logger following Final Progress update
4
‘Date:20-gun-2007 15:01:14 User:Pooja Sujith
Defect cause updated to 40: General - User
‘Date:20-Jun-2007 15:01:17 User:Pooja Sujith
(CALL PCO133933 closed: Category 70 Type L
is can be closed. Mark to add a statement to
ing mode paramenters. The smartpost
POL00001265
POL00001265
life
closed.
MSU-Indt Mgt
es = (version unspecified)
MSU-I indt Mgt
F/338/3