Middleware that allows a sender application to send delivery requests to delivery services https://git.egiz.gv.at/moa-zs/atom?h=2.0.0-RC9 2020-03-03T07:53:43+00:00 2020-03-03T07:53:43+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2020-03-03T07:50:12+00:00 urn:sha1:3e0238d96cb58459b5a67d2d113ba5469a3a8978 - Update zusemsg schema to version 2020-02-26 2020-03-03T07:53:43+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2020-03-03T07:53:11+00:00 urn:sha1:260200a55c07a9a5a8beab70dcf1980e522c438b 2020-02-18T13:05:18+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2020-02-18T11:19:01+00:00 urn:sha1:8400a1f99e7377e164a0d995359ff8c00a52c4e2 - Fix: Parser Error that occurs when MOA ZS goes into service timeout. - Fix: Improve exception handling on MOA ZS Async. - Before: When MOA ZS processes delivery request but hits a timeout, MOA ZS would answer syncronously to the Sender app and forward the result assynchronously at a later point. If an exception were to occur after the timeout, MOA ZS would swallow this exception. - Now: If an exception occurs, MOA ZS converts the exception into a response and hands it over to the sink hub for proper processing of the event. 2020-02-18T13:05:18+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2020-02-18T13:04:27+00:00 urn:sha1:c257eea0453dfb484cf4f7a68ccc04a472d08bb7 2019-12-09T09:25:02+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-09T09:25:02+00:00 urn:sha1:1d2aafe0cd6607a48d880c007881768079e49060 - Handle InterruptedExceptions as discussed in https://stackoverflow.com/questions/3976344/handling-interruptedexception-in-java - Remove unused imports. 2019-12-09T08:38:39+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-09T08:36:48+00:00 urn:sha1:5cb5e4803e315bb717c9db882f60c848da8e660c - Refactor: Move genTimestamp from ITMzsServiceTest to TestUtils (because needed in multiple test cases). - application.yaml: Complete app-client config in config profile. 2019-12-09T07:53:56+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-09T07:53:56+00:00 urn:sha1:a9585d867a2b432f6d75237e0857dd8af2daf554 2019-12-06T12:18:12+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-06T12:18:12+00:00 urn:sha1:ff1e38bfa954dd747a5ff185dfe51c120d5ab5e7 - Before: Upon receipt of a message via the msg/ endpoint, MOA ZS would immediately acknowledge the receipt without verifying that the message was successfully processed by the backend. - Now: MOA ZS receives a message via the msg/ endpoint, forwards it to the sinks, and acknowledges the receipt if and only if the processing succeeded. 2019-12-05T08:16:36+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-05T08:16:36+00:00 urn:sha1:cf90865ce21f246a0358fd291324f511c5ed6e90 - mzs Schema Change: Introduce new type mzs:ERVConfirmedDelivery (which is a mzs:MessageType extension) and replace mzs:DeliveryNotification/msg:ERVConfirmedDelivery with mzs:ERVConfirmedDelivery. Reason: Necessary to provide all parameters to sender application (AppDeliveryID, DeliverySystem, ZSDeliveryID, a.o.). - Adapt Msg2MzsConverter accordingly. 2019-12-03T08:08:44+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-02T13:26:42+00:00 urn:sha1:8799a27e8d73c5e079d549f6d76abf861d75ee9e - Problem: I fixed CompletableFuture.*async within the DeliveryRequest flow, but forgot to do the same for the DeliveryRequestStatus / DeliveryNotification flow. - Solution: Ensure that all CompletableFuture.*async() invocations have Spring's task executor attached.