vwiki

User Tools

Site Tools

Trace:
rm25645

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rm25645 [2018/06/04 09:11] – [Reproduce] kalaschnikowrm25645 [2018/06/12 10:53] (current) – [Analyze] kalaschnikow
Line 1: Line 1:
 +====== rm25645 AIRS_PRD: Error: PO Finalizer Job auf PRD ======
 +
 +https://cust-projects.seeburger.de/redmine/issues/25645
 +
 +===== Description =====
 +...
 +
 +
 +===== TODO =====
 +  * **+** Analyze
 +  * **+** Reproduce
 +  * **+** Fix
 +  * **-** Test
 +
 +===== Analyze =====
 +Probleme macht folgende OTD-Line:
 +<code sql>
 +Insert into tOTDLINE__ 
 +(COTDLINEID,COTDRELATIONID,COTDOFFICERID,COTDMATERIALID,CBASELINEID,CBASEHEADERID,CKPIHORIZON    ,COVERALLCOLLABSTATUS,CSUPPLIERCOLLABSTATUS,CCUSTOMERCOLLABSTATUS,CGRADING,CINITIALGRADING,CSUPPLIERCOLLABENDDATE,CCUSTOMERCOLLABENDDATE,CSUPPLIERCAUSE    ,CSUPPLIEREVIDENCE                                 ,CCUSTOMERCAUSE,CCUSTOMEREVIDENCE,CSUPPLIERUSERID   ,CSUPPLIERUSERNAME  ,CCUSTOMERUSERID,CCUSTOMERUSERNAME,CSUPPLIERCOLLABTIMESTAMP,CCUSTOMERCOLLABTIMESTAMP,CSCOREDFORKPICALCULATION,CFLEXFIELD1,CFLEXFIELD2,CFLEXFIELD3,CFLEXFIELD4,CFLEXFIELD5,CFLEXFIELD6,CFLEXFIELD7,CFLEXFIELD8,CFLEXFIELD9,CFLEXFIELD10,CDELETIONFLAG,CPURGROUP,CLINEPONUM,CPOSNUM,CRSNUM,CORDERTYPE,CORDERSUBTYPE,CDOCTYPE,CSPARESPRIO,CAGREEDREQDATE ,CAGREEDREQQTY,CRECQTY,CFINALDELIVERY,CLINEDESCR                    ,CFITCUSTMATERIAL,CCOLLABALLOWEDONOTD,CGOODSARRIVALDATE,COTDONTIMEFROM,COTDONTIMETO,CVERYEARLYTO,CEARLYTO       ,CLATEFROM      ,CVERYLATEFROM        ,CCOLLABTIMEFRAMEREFDATE,CSUPPLIERCOLLABORATED,CCUSTOMERCOLLABORATED,COTDMANAGEMENTSTATUS      ,CENDOFREOPENPERIOD,COTDGRADINGVERYEARLYTO,COTDGRADINGVERYLATEFROM,CLASTEXPORTTIMESTAMP,CEXPORTED) VALUES
 +('365664'  ,'32264'       ,'45885'      ,'1825846'     ,'25677660' ,'7672669'    ,'1496268000000','CLOSED'            ,'REJECTED'           ,'ACCEPTED'           ,'ONTIME','LATE'         ,'1525557599999'       ,'1525730399999'       ,'Customer ERP/MRP','Cartes en SAV date à changer en 2018 et non 2017',null          ,null             ,'SANDRINESAUVAGET','Sandrine SAUVAGET','SYSTEM'       ,'SYSTEM'         ,'1525243280319'         ,'0'                     ,'1'                     ,null       ,null       ,null       ,null       ,null       ,null       ,null       ,null       ,'-1'       ,'-1'        ,'0'          ,'8J1'    ,'50660803','00001','0001','OTHER'   ,'-'          ,null    ,null       ,'1497650399000','8'          ,'8'    ,'0'           ,'CARTE CABLEE HT VES F1299392','4215206'       ,'1'                ,'1517007599000'  ,'3'           ,'1'         ,'0'         ,'1497650399000','1497995999000','9223372036854775807','1524576976148'        ,'1'                  ,'0'                  ,'Collaborated by Supplier','1530914399999'   ,null                  ,null                   ,'1525802401271'     ,'1'      )
 +;
 +</code>
 +In dem Changelog sieht man, dass der Vorgang "Customer modify" am 24.04.2018 14:36:16.291 stattfand. Dieser Vorgang durfte eigentlich nicht stattfinden, da die PO den Status "RECEIVED" hatte und ein Wechsel daraus nur über einen GR oder PO Import möglich ist.
 +Verdacht: der Übergang ist nicht transaktionssicher, da 117 Millisekunden davor (am 24.04.2018 14:36:16.174) der Vorgang "Supplier Accept" stattfand, der Status von CCOR nach RECEIVED geschaltet hat.
 +===== Reproduce =====
 +
 +1. Import PO\\ 
 +  * Status = NOP
 +2. Supplier Accept\\ 
 +  * Status = OPEN
 +3. Stock Movement\\ 
 +  * Status = RECEIVED
 +4. Import PO\\ 
 +  * Status = CCOR
 +5. Breakpoint  in ''POCollabEngine.processCollabFromGUILine()'' setzen\\
 +6. Customer Modify (Req.Date ändern)\\
 +  * Debugger bleibt stehen
 +7. Supplier Accept\\
 +  * Debugger bleibt am Breakpoint stehen, aber wir lassen DIESEN Thread laufen (der "vorherige" Thread von Customer bleibt immernoch stehen!)
 +8. Customer Modify Thread laufen lassen\\
 +  * Jetzt ist der Satz kaputt: die PO ist in dem "finalen" Status, aber der cDeletionFlag bei der OTD line steht auf 0. Wenn man jetzt den Finalizer Job laufen lässt, wird er einen Fehler wg. Constraintverletzung bekommen. 
 +
 +----
 +Der Job geht auf Fehler weil er versucht eine neue Line anzulegen, welche die UNIQUE Constraint hat, die bereits existiert (UNIQUE_OTDLINE_PER_POSL= cBaseLineId + cBaseHeaderId). Aber bevor eine neue Line erstellt wird, wird die alte gesucht und gelöscht (s. ''OTDManagerDAOImpl.initialCreationOTDLine()''). Die alte Line wird aber gesucht nur für die Kriterien cBaseLine + cBaseHeaderId + cDeletionFlag=1. D.h. eine solche Situation kann entstehen, wenn wir eine Line haben, bei der cDeletionFlag=0 ist.
 +
 +Bei dem Update der PO wird geprüft, ob sie OTD-relevant ist,  und wenn ja, die alte OTD-Line wird zur Löschung markiert (cDeletionFlag=1). Das wird gemacht, um danach, wenn der PO-Status "final" wird, diese Line zu löschen und mit der anderen zu ersetzen. Genau an dieser Stelle kann passieren, dass die alte Line stehen bleibt. Nämlich in dem Fall, wenn die alte PO OTD-relevant war und die neue nicht. 
 +
 +
 +
 +---- 
 +
 +Burkhard:\\ 
 +Das ist alles was ich aus der Historie entnehmen kann: zuerst geht die PO von NOP auf Received durch eine Goods Receipt Nachricht, dann wieder zurück nach CCOR. Vielleicht hilft das den Fall nachzustellen.
 +
 +Das kann man reproduzieren, wenn man: 
 +  * eine PO importiert (PO Status wird zu NOP)
 +  * dann eine GoodsReceipt Nachricht mit voller Menge importiert (PO Status wird zu RECEIVED)
 +  * dann eine "Update-PO", bei der aber das Lieferdatum geändert wurde (PO-Status wird zu CCOR)
 +
 +
 +
 +Damit der Finalizer Job auf einen Fehler läuft, müssen 2 Bedingungen erfüllt sein:
 +  * Status der POScheduleLine muss eins von folgenden Werten sein:
 +    * 1000 CANREQ
 +    * 1300 CCOR
 +    * 2000 SAWC
 +    * 2100 SCOR
 +  * OTDLine muss cDeletionFlag auf 0 haben
 +
 +Misc:
 +  * ''OTDManagerDAOImpl.insertOTDLine()'' **speichert nicht** den Wert von ''otdLineModel.isDeletionFlag()'' 
 +  * ?
 +==== Misc ====
 +
 +=== 1 ===
 +
 +Some helpful SQL statements:
 +<code sql>
 +SELECT * FROM TAIRPOHEADER where cPONUM like 'rm%001'
 +
 +SELECT * FROM TAIRPOSCHEDULE where CLINEPONUM like 'rm25645%001' 
 +
 +SELECT * FROM TAIRCHANGELOG where CSUBOBJECTREFERENCE=5003673
 +
 +SELECT * FROM TAIRCHANGELOG where cActionTime > 1527079088222 
 +--and cLocalOp like 'Stock%'
 +
 +-- fetch OTD lines:
 +SELECT * FROM TOTDLINE order by cOTDLineID;
 +
 +
 +</code>
 +
 +=== 2 ===
 +
 +Komischerweise liefert:
 +
 +<code java>
 +collabId = POCollabStatus.getUniqueCollabTransactionId(new Config(IPOConstants.CLIENT_ID), IPOConstants.COLLAB_PROCESS_SM_GR);
 +</code>
 +im SMManagerEJB:242 den Wert -1. Warum?
 +
 +
 +=== 3 ===
 +
 +Wichtige Stelle: ''SMImportProcessor.processSTA()''
 +
 +===== Fix =====
 +
 +In ''POCollabEngineEJB.processCollabGUILine()'' bevor man die Änderungen an der POLine gemacht werden muss das POCollabModel aktualisiert werden (von der DB neu geholt). So wird die Dateninkonsistenz vorgebeugt.
 +===== Misc =====
 +
 +===== Result =====
 +