aboutsummaryrefslogtreecommitdiff
path: root/src/main/java/at/gv/egiz/moazs/backend
AgeCommit message (Collapse)AuthorFilesLines
2020-02-18Timeout & Assync FixesChristof Rabensteiner1-1/+1
- 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.
2019-12-09Refactor & FixesChristof Rabensteiner2-7/+3
- Handle InterruptedExceptions as discussed in https://stackoverflow.com/questions/3976344/handling-interruptedexception-in-java - Remove unused imports.
2019-12-06Change msg service: Acknowledge Response iff Backend SucceedsChristof Rabensteiner2-19/+26
- 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-03Finalize "Removal of JAXB Class Not Found Fix"Christof Rabensteiner3-10/+20
- 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-29Refactor & Fix Client Creation in Client FactoryChristof Rabensteiner2-3/+3
- 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-29Alter Case Handling "Get Notification where AppDeliveryID is unknown"Christof Rabensteiner1-5/+32
- 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-10-30Refactor: Rename ClientFactory.create InterfaceChristof Rabensteiner2-3/+3
- Reason: Consistency
2019-10-04Add @author Tag Where It Was MissingChristof Rabensteiner7-0/+28
2019-10-04Add Licenses, NOTICE, and License HeaderChristof Rabensteiner7-0/+147
2019-10-02For {TNVZ, MSG}: Switch to Soap 1.2Christof Rabensteiner1-1/+1
- But: Leave MZS Interface at Soap 1.1 - Add ClientFactory.createSOAP11 to ensure that we can talk back to the app.
2019-09-03Rename MzsClient to AppClientChristof Rabensteiner2-2/+2
...since it's a client that communicates with the app.
2019-08-30Fix Tnvz TypoChristof Rabensteiner1-2/+2
- sed 's/tvnz/tnvz/'
2019-08-28Ensure that Each Step of Each Backend Process is LoggedChristof Rabensteiner6-3/+26
2019-08-23Add Trace Logs to DeliveryRequestBackendChristof Rabensteiner1-0/+36
2019-08-23Fix: JAXB + Java >= 9 Class Loader Bug & Ensure Tomcat DeploymentChristof Rabensteiner1-2/+3
- Problem: Jaxb + JAVA >= 9 Runtime + Tomcat = ClassNotFoundException: ContextFactory. Reason: Apparently, jaxb uses the "wrong" classloader (the system classloader via the thread classloader) and this classloader does not know about jaxb api's and implementations at runtime since oracle decided to move jaxb* out of JRE. Solution: create a new thread, override the thread's "thread" classloader with the "class" classloader and do all jaxb interactions in that thread. See: https://sjhannah.com/blog/2018/11/21/jaxb-hell-on-jdk-9/ - Move "run jaxb interactions in own thread with class class loader" code into own component (JaxbClassNotFoundFix, runInTheadWithClassClassLoader) and wrap ClientFactory and Marshaller code into the "runInTheadWithClassClassLoader". - Ensure that app can be deployed in a Tomcat container (by following this guide: https://www.baeldung.com/spring-boot-war-tomcat-deploy)
2019-08-19SignatureVerifier: Log incoming request to debugChristof Rabensteiner1-0/+11
2019-07-22Test Flow of DeliveryRequest from "End-To-End" & Fix BugsChristof Rabensteiner2-7/+8
Schema Changes: - Remove mzs:DeliveryRequest/TnvzMetaData because all metadata fields can be collected from DeliveryRequest and redundancy is not needed. Fixes and Refactoring in preprocess: - MzsDeliveryRequestValidator: Instead of returning false, throw an exception when a condition is not met, and explain which condition is not met / why it is not met in the exception's message. - Integrate interface change in ConfigProfileGenerator and DeliveryRequestAugmenter. - Rewrite and simplify DeliveryRequestAugmenter's augmentation. - ConfigUtil Fixes: Ensure that we do not override the wrong parameters while merging. This error appeared in tnvz / msg client, connection / receive timeout, key / trust store, and lax hostname verification / trust all. Fix Bugs in Interceptor / SoapUtils: - Problem: DOM access and information extraction was implemented somewhat sloppy. - SolutioN: Change DOM access interface to access DOM more efficiently. Add boundary checks and handle edge cases while extracting information from SOAP Messages. - Test those changes properly. Testing: - Implement Delivery Request Flow in ITEndToEndTest. - Start application on random port instead of fixed port when running integration tests. - Add assertions to tests in ITMzsServiceTest suite. Others Bug Fixes: - ServicesConfig: Ensure that mzs service and msg service run on different endpoint addresses (/msg and /mzs). - DeliveryRequestBackend: Throw exception when binary message is missing. Don't wrap the exception. - SaveResponseToFileSink: Wrap Response in JAXB Element (otherwise, marshaller does not recognize it)
2019-07-18Integrate Mzs Service Timeout and Handle Async ResponsesChristof Rabensteiner3-51/+67
- Service Timeout : Add service timeout to mzs schema (DeliveryRequest / Config), application.yaml, convert service timeout from spring environment to Config, and merge service timeouts in Configs. - Handling of Asynchronous DeliveryRequestStatus: Move "Applying Response Sinks" from backend into dedicated component "MsgResponseSinkHub" and integrate SinkHub into MzsService (apply sinks to asynchronous responses). - Remove line breaks in SignatureVerifier's log statements. - Revise documentation of parameters in application.yaml.
2019-07-17Put MoaZSException on Diet & Handle Edge CasesChristof Rabensteiner3-39/+52
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-16Implement ForwardResponseToService Sink And All Its ImplicationsChristof Rabensteiner2-5/+48
MZS Schema Change: - Add configuration for ForwardResponseToServiceSink (add parameters in mzs:DeliveryRequest/Config) - Add sink configuration in application.yaml, convert from Spring Environment to ConfigType, and merge ConfigTypes. - Validate sink configuration completeness. Contract added: - Add contract mzs2app.wsdl: This contract specifies how mzs:DeliveryRequestStatus' and mzs:DeliveryNotifications are forwarded to the sender application. - Implement "ForwardResponseToService" Sink. - Add and implement MsgResponse.sendToMzsClient() : This is a somewhat unfortunate solution because, intuitively, sending should be done by it's caller, the "ForwardResponseToService"-sink. However, this solution prevents differences between msg:DeliveryRequestStatus and msg:DeliveryNotification (and code that needs to handle differences, i.e. sending) from sprawling outside of the respective MsgResponse derivatives. We move the entire "send" process into MsgResponse to prevent a hard-to-maintain "if type == notification then do x else to y" construct in ForwardResponseToServiceSink. Otherwise, introducing the MsgResponse wrapper was pointless.
2019-07-15Save Response To File Sink: Add Path to Configuration + FixChristof Rabensteiner2-10/+8
- Fix in ConfigUtil: SaveResponseToFile boolean would override LogResponse configuration (Copy Paste Error).
2019-07-12Allow App To Choose Between MsgResponse SinksChristof Rabensteiner3-11/+88
- MZS Schema Change: Add "MsgResponseSinks" element to mzs:DeliveryRequest/Config that allows sender to configure how MsgResponses should be archived. - ConfigUtil: Interpret MsgResponseSink parameters from Spring Environment and merge with ConfigType. - MsgResponseBackend: Send responses to sinks according to MsgResponseSinks in Config - application.yaml: Add MsgResponseSinks parameter to configuration. - Uncouple Sink implementations from java.util.function.Function, because the sink interfaces are going to differ and there is no need to unite them under one interface. - Add and test LogResponseSink, which logs responses to it's logger. - MsgResponse: Add JAXB getter for response. Reason: Can be passed to marshaller.
2019-07-12Renamed and Simplified SignatureVerifierChristof Rabensteiner1-29/+38
2019-07-09Refactor Needles Interfaces and Rename "process" to "backend"Christof Rabensteiner4-0/+392
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.