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-RC6 2019-12-03T09:19:07+00:00 2019-12-03T09:19:07+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-12-03T09:19:07+00:00 urn:sha1:937e48041e71f0dc264ba10542631e19fa6ff3a6 - Update Changelog. - Move Changelog to dedicated file. - Restructure / reframe specification. 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. 2019-11-29T14:56:44+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-29T14:56:44+00:00 urn:sha1:6dbe979e0b6bd6236db304b034ad592a4aeacabc - Refactor: Replace createSoap1{1,2} with create{Tnvz,App,Msg}Client. Configure each method with zusespec's specific parameters. Reason: Each service requires different parameters (e.g. with / without MTOM? soap11 / soap12? store responses in binary respository - yes/no?). These parameters could be placed in the client configuration of application.yaml. Since the parameters are tied to zusespecs, they do not need to be configurable via application.yaml. Another benefit for this refactoring is to improve readability. - Fix: Disable "Store Response" for TNVZ Client and App Client 2019-11-29T13:54:28+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-29T13:54:28+00:00 urn:sha1:a5b8668c0c7916a8fe2b84122d537a3e0bd67002 - Former: Fail with Exception. - Now: Issue a warning and fall back to default configuration profile after verifying that sinks in default configuration profile are correctly configured. - Refactor: Make DEFAULT_CONFIG_KEY static. 2019-11-29T11:55:06+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-29T11:55:06+00:00 urn:sha1:5fffae99208c7a99a5e3e8f196a6004debcc9c81 - Problem: MOA ZS converts the mzs:Receiver/Person to msg:Receiver/Person even if mzs:Receiver/Person is null. - Solution: Distinguish Cases. - Add ClearingProfilID in mzs2msg conversion. 2019-11-28T14:32:36+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-28T14:32:36+00:00 urn:sha1:b10ecd3dc4e2633065db6f3e6aa9fe0972a2ca07 2019-11-22T13:18:37+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-22T13:18:37+00:00 urn:sha1:a33b5e1dec56c853992233e8d2dd632ad96f454e 2019-11-22T13:05:10+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-22T12:57:41+00:00 urn:sha1:7acd8cf9b3bd0aacea61fff3a07e17b9b57ad8cc - Problem: When activating the QueryPersonRequest, the TNVZ returns an Identification element that needs to be integrated into the msg:DeliveryRequest as a child of Receiver. The Identification child is mutually exclusive to another sequence consisting of (Person, AustrianAddressesOnly, Address). I forget to delete the sequence when adding the Identifcation element and violate the the msg schema. - Solution: Delete sequence when adding Identification. - Test the fix in test case. Thanks to Johannes Hörtnagl for pointing out the problem. 2019-11-22T12:56:31+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-22T12:56:31+00:00 urn:sha1:9cd371997e9671301d7bae68d75af72687c2860d 2019-11-07T07:43:53+00:00 Christof Rabensteiner christof.rabensteiner@iaik.tugraz.at 2019-11-07T07:43:53+00:00 urn:sha1:ab44a755d2b3b168bbea7de76dbecf7ce92709e0