moa-zs/src/main, branch 2.0.0-RC8

Timeout & Assync Fixes

2020-02-18T13:05:18+00:00

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

Refactor & Fixes

2019-12-09T09:25:02+00:00

- Handle InterruptedExceptions as discussed in https://stackoverflow.com/questions/3976344/handling-interruptedexception-in-java - Remove unused imports.

Change msg service: Acknowledge Response iff Backend Succeeds

2019-12-06T12:18:12+00:00

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

Fix Missing Parameters in ERVDeliveryConfirmed Notification

2019-12-05T08:16:36+00:00

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

Finalize "Removal of JAXB Class Not Found Fix"

2019-12-03T08:08:44+00:00

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

Refactor & Fix Client Creation in Client Factory

2019-11-29T14:56:44+00:00

- 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

Alter Case Handling "Get Notification where AppDeliveryID is unknown"

2019-11-29T13:54:28+00:00

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

Fix NPE When Receiver Is Identified by Identity

2019-11-29T11:55:06+00:00

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

Fix Msg Schema Error: Honor Mutual Exclusiveness of

2019-11-22T13:05:10+00:00

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

Fix Error in TNVZ QueryPerson Request

2019-11-07T07:06:38+00:00

- Problem: When assembling the TNVZ Query Person Request, I convert the Sender with msgp's ObjectFactory.createPerson. The marshaller will then create a Corporate body like this: What we really want is this: - Solution: Replace createPerson with createCorporateBody. - Thanks to Johannes Hörtnagl and Christoph Kaiser-Feistmantl for the feedback.