====== 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