aboutsummaryrefslogtreecommitdiff
path: root/src/test/java/at/gv/egiz/moazs/DeliveryRequestBackendTest.java
AgeCommit message (Collapse)AuthorFilesLines
2020-03-03Update Copyright to 2020Christof Rabensteiner1-1/+1
2019-11-29Refactor & Fix Client Creation in Client FactoryChristof Rabensteiner1-2/+2
- 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-10-30Refactor: Rename ClientFactory.create InterfaceChristof Rabensteiner1-2/+2
- Reason: Consistency
2019-10-04Add @author Tag Where It Was MissingChristof Rabensteiner1-0/+4
2019-10-04Add Licenses, NOTICE, and License HeaderChristof Rabensteiner1-0/+21
2019-07-17Put MoaZSException on Diet & Handle Edge CasesChristof Rabensteiner1-18/+10
Reason: MoaZSException (and: its builder) were used to collect intermediary results while stepping through the delivery request backend. These results were needed to generate meaningful responses towards the sender application in case of error. However, the builder sprawled over too many interfaces (e.g. DeliveryRequestBackend and TNVZHelper) and it became difficult to understand from where intermediary results originated. Solution: Put MoaZSException on diet: - Remove all DeliveryAnswer fields from MoaZSException and refactor code base to ensure that the removed fields get sourced by other means. - Remove Builder since amount of parameters is manageable. Refactor DeliveryRequestBackend: - Instead of passing down the builder and using MoaZSException as the only source for intermediary results, we collect available results at the outermost stack frame (DeliveryRequestBackend.accept) and only retrieve results via exception if those results appear somewhere down the stack frame (E.g. PredviceNoteSent). We collect available results with the "fallbackAnswerBuilder" and switch to the msg client response, once received. Refactor MsgResponseBackend: - Handle cases (response missing, binary response missing) properly. - Integrate changes from MsgResponse.generateError() Refactor TVNZHelper: - Remove MoaZSExceptionBuilder from all interfaces. Refactor MsgResponse.generateError: - Change interface such that it's more intuitive. - Implement NotificationResponse.generateError. - Implement RequestStatusResponse.generateError. Others: - Replace all invocations against MoaZSException.Builder.
2019-07-09Refactor Needles Interfaces and Rename "process" to "backend"Christof Rabensteiner1-0/+203
Reason: - Interfaces with a single method can be replaced with interfaces from java.util.function. - Less interfaces = less code = less maintenance! - Spring can inject beans by name so we name dependencies correctly to prevent ambiguity. Others: - Rename process to backend since backend gives a better description of its components.