====== 09.10.2017 Montag ======
===== rm#21582 EDI Scheduler does not remove cascade ID in parallel scenarios =====
https://cust-projects.seeburger.de/redmine/issues/21582
* Das Export wird über die UI angestoßen (als Supplier).
* Statusmeldung vom BIS:
2.2
;;PORT123;LS;PGICLNT001
PORT456;LI;SUPPLYON
100000000122
20100202080000
S23943
20101201131402
false
SUCCESS
Die Statusmeldung kann man simulieren in dem man im JMS Client eine "SO-StatusNotification" schickt.
==== Nütliches Zeug ====
* 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
==== TODO ====
* **-** 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.
==== Misc ====
* 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.
==== rm#22382 CR 22025: Concession - Integration of "Spot-It" application (Airbus Proof of Concept) ====
https://cust-projects.seeburger.de/redmine/issues/22382
Das Ticket steht momentan auf "ON HOLD".
Notizen siehe [[http://vwiki.wialon-consulting.de/doku.php?id=kw40_02.10.2017_-_08.10.2017#rm_22382_cr_22025concession_-_integration_of_spot-it_application_airbus_proof_of_concept1|Donnerstag 05.10.2017]]
===== Abend =====
==== Palletways ====
* **+** checken, ob's tut
* **+** Mail an Hr. Grewe schreiben
==== Steuervoranmeldung ====
* **+** Rechnungen sammeln
==== Wiatrack ====
* **-** Log von gestern und heute anschauen (sind Lücken vorhanden?)
==== Bauer Gear Motor ====
* **-** mit der eigenen App versuchen sich mit dem Board zu verbinden und Tastendrücke abzufangen