https://cust-projects.seeburger.de/redmine/issues/21582

• Das Export wird über die UI angestoßen (als Supplier).

• Statusmeldung vom BIS:

<?xml version="1.0" encoding="UTF-8"?>
<TransmissionEnvelope>
     <SO-AirSupply>
          <ControlArea>
               <Version>2.2</Version>
               <SenderInfo>;;PORT123;LS;PGICLNT001</SenderInfo>
               <ReceiverInfo>PORT456;LI;SUPPLYON</ReceiverInfo>
               <ContentInfo>
                    <ExternalMessageID>100000000122</ExternalMessageID>
                    <CreationTimeStamp>20100202080000</CreationTimeStamp>
               </ContentInfo>
               <ProcessingInfo>
                    <InternalMessageID>S23943</InternalMessageID> <!-- tAirPOSchedule.cExportMsgId -->
                    <ReceivingTimeStamp>20101201131402</ReceivingTimeStamp>
                    <TestFlag>false</TestFlag>
               </ProcessingInfo>
               <Validation>
                    <Status>SUCCESS</Status>
               </Validation>
          </ControlArea>
     </SO-AirSupply>
</TransmissionEnvelope>

Die Statusmeldung kann man simulieren in dem man im JMS Client eine “SO-StatusNotification” schickt.

• Job-Runs werden in TAIREDIMESSAGES protokolliert. IDs holen: SELECT * FROM TAIREDIMESSAGES order by cID DESC
• Batch-Größe wird vom Parameter LIMIT_EXPORT_POSCHEDULELINE bestimmt
• Wichtige Klasse (laut Burkhard): POExportXMLM2MProcessor
• TAIRPOSCHEDULE enthält Orders, wenn die Order exportiert ist, müsste cExportAllId nicht leer sein.

-- set config key
UPDATE tConfig SET cValue=32 WHERE cKey = 'LIMIT_EXPORT_POSCHEDULELINE'
 
-- reset POs
UPDATE TAIRPOSCHEDULE SET CEXPORTID=NULL, CEXPORTALLID=NULL, cExported=NULL WHERE cREFHEADERID>=538845
 
-- find last message
SELECT * FROM TAIREDIMESSAGES ORDER BY cID DESC

• - Parallelläufe simulieren und die im Ticket erwähnte Exception bekommen
• - …
• - Catch ContainsNoDataException in StatusMessageImportHandler after starting a new job loop and reset the cascade ID. In this case, the scheduler has finished and the cascade ID must be reset.
  • In der StatusMessageImportHandler.processRootElement() gibt es einen “else”, der genau den richtigen Code enthält. Aber es wird eine GeneralFailureException gefangen, ImportException geworfen und resetExportAllFlag() wird nicht aufgerufen.

• Evtl. liegt es an einer Exception beim zurücksetzen der cExportAllId auf null (s. POExportXMLM2MProcessor.markPosForExport() Zeilen 186 oder 192)
  • Dann sollte man im Log den Satz “Unexpected error when marking POs for export” bzw. “Unexpected error when marking POs for export with message ID” sehen
• SchedulerManagerEJB.resetExportAllFlag()
• SchedulerManagerEJB.export()
  • Dann sollte man im Log den Satz “We could not write message status or reset the export flags. This is a pretty uncool situation because we cannot inform the user about the failed export. So hope someone can read this…” finden können
• In meiner DB gibt es keine Sätze, die hängen geblieben sind, weil folgende Abfrage 0 Sätze liefert:

SELECT * FROM TAIREDIMESSAGES WHERE cMessageId IN (SELECT DISTINCT cExportAllId FROM TAIRPOSCHEDULE WHERE cExportAllId IS NOT NULL);

D.h. in tAirEDIMessages hat keine Sätze, die zu den “hängenden” cExportAllId-s gehören.

https://cust-projects.seeburger.de/redmine/issues/22382

Das Ticket steht momentan auf “ON HOLD”.

Notizen siehe Donnerstag 05.10.2017

• + checken, ob's tut
• + Mail an Hr. Grewe schreiben

• + Rechnungen sammeln

• - Log von gestern und heute anschauen (sind Lücken vorhanden?)

• - mit der eigenen App versuchen sich mit dem Board zu verbinden und Tastendrücke abzufangen