aboutsummaryrefslogtreecommitdiff
path: root/src/main/java/at/gv/egiz/moazs/MoaZSException.java
AgeCommit message (Collapse)AuthorFilesLines
2019-07-18Integrate Mzs Service Timeout and Handle Async ResponsesChristof Rabensteiner1-1/+0
- 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 Rabensteiner1-137/+21
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-09Minor Fixes And RefactoringChristof Rabensteiner1-16/+9
- Fix typo in SafeResponseToFileSink. - MoaZSException: Simplify constructor by replacing lots of arguments with the builder instance. - Fix minor codesmells (unused imports, superfluous braces).
2019-07-08Implement Zuse2App ServicesChristof Rabensteiner1-34/+65
- Add zuse2app.wsdl contract. - Add MsgResponse as an type-agnostic view for DeliveryRequestStatus and DeliveryNotification messages. Reason: Both DeliveryNotification and DeliveryRequestStatus messages have similar fields and need to be treated similarly (e.g.: receive from msg service, store to repository, verify signature, store to file...). In order to prevent duplicated code, the wrapper interface provides a type-agnostic view onto these messages for depending components to operate on. - Add MsgResponseHandler interface; decides how to process MsgResponse. Also implement this handler with a multi-threaded single-node implementation. - Add MsgResponseSink interface; decides how to archive MsgResponse. - Implement and test SafeResponseToFileSink. Change Identifier for MsgResponses: - Before, DeliveryRequestStatus and DeliveryNotifications had their own repositories. Now, both types are stored in the same repository (the MsgResponse repository) to streamline the handling of MsgResponses. We need to change the identification of MsgReponses, otherwise the identifiers (AppDeliveryID) clash. - MsgResponses are not identified by: <AppDeliveryId>+<typeSpecificSuffix> - Rewrite StoreSOAPInterceptor to accommodate fact that, both DeliveryRequestStatus and DeliveryNotification messages have different IDs upon storage / retrieval. Restructure packages and components as follows: - client: All components that are involved when consuming a web service. - process: "fabric" of MoaZS; contains business logic that orchestrates back-end tasks of MoaZS's operational services, e.g.: by processing a delivery request. - service: Implementation of MoaZS's front-end services. Refactoring: - MoaZSException: Remove unused fields. Before: Store mzsrequest, tnvzresult, msgrequest and msgresult as members. Now: Only keep the fields that are needed later, e.g for generating a msg:DeliveryRequestStatus element. Add copy constructor to Builder. - Put storage of byte[] into a dedicated "BinaryRepository". Reason: This was useful in a former design. Now it's not really needed anymore. - Put "create Endpoint" code into EndpointFactory. Reason: Eliminate duplicated code when configuring a service. Testing: - Activate Stacktraces in surefire.
2019-07-02Implement And Integrate tnvz:QueryPersonRequest.Christof Rabensteiner1-0/+10
- Merge TnvzClient and TnvzResultVerifier to TnvzHelper; TnvzHelper now builds the QueryPersonRequest, sends it to the tnvz port and evaluates the result. - Publish some interfaces in Mzs2MsgConverter because they are needed by TnvzHelper. - Generalize MsgClientFactory to ClientFactory such that it can be used to generate arbitrary SOAP clients (e.g. also for tnvz!). Schema Changes to accomodate Tnvz's QueryPersonRequest: - Add optional tnvz:AustrianAddressesOnly and optional TnvzMetaData to mzs:mzs:DeliveryRequest. Removed Unit Tests: - Remove subset of SameThreadDeliveryPipeline testcases (mimetype related) because its logic moved to TnvzHelper.
2019-06-26Protect MsgClient via SSL (ink Client Authentication)Christof Rabensteiner1-1/+5
- Add Component to create SSLContexts with own Key- and trust store. - Inject SSLContext into HTTP Client. - Add EAAF-Components Core Dependency, which is needed by SSLContextCreator (KeyStoreUtils). Schema Changes in mzs:DeliveryRequest/Config: - Got Rid of mzs:DeliveryRequest/Config/Server. In mzs 1.4.1, Server replaces the result of zkopf query person request. Since this zkopf interface does not exist anymore, Server was removed. - Add ClientType, which holds all parameters needed to connect to a service (Url, SSL params, a.o.). Configuration: - Add default parameters for SSL Clients in application.yaml. - Merge default parameters into incoming mzs:DeliveryRequests. MoaZSException Fixes: - Remove "Extends throwable" from Builder. - Add convenient shorthand init method (message, throwable). Refactor: - Put "determinePath" to FileUtils. - Put string related utility functions into StringUtils.
2019-05-28Integrate Sign.Verification and Improve Error Handling of PipelineChristof Rabensteiner1-7/+116
- Ensure proper communication of errors between pipeline and mzs service by converting MoaZSExceptions into DeliveryRequestStatus messages. - Revise MoaZSException: Add optional fields; those fields are a) helpful to construct meaningful error messages and b) optional because, depending on where an exception appears, either existent or non-existent and thus optional. Add inner-class Builder. - Integrate Signature Verification into pipeline and add Stub for SignatureVerification. - Move TNVZResponse's Mimetype check into dedicated class (Reason: separate abstration layers). - Update api changes in testcases.
2019-05-23MZS Schema Changes + Changes in InterfaceChristof Rabensteiner1-0/+4
- MZS cant reply with a msg:DeliveryRequestStatusType to a mzs:DeliveryRequest. Reason: unmarshalling a msg:DeliveryRequestStatusType with JAXB (after receiving the msg reply) breaks the signature in msg:DeliveryRequestStatusType. Why? Because JAXB marshalling tinkers with the namespaces and, as for the current state of knowledge, we cannot configure the JAXB marshaller to reconstruct a XML Document byte-by-byte such that a signature that went through this process can be verified successfully (see [1]). - For this reason, we revert back to mzs:DeliveryResponse and add new fields / remove obsolete fields / capture all changes between zusemsg 1.5.3 and zusemsg 2.0.0. - The easier solution would be to wrap and transmit signed data + signature in a binary (base64) container, such that apache cxf and other web service frameworks won't unmarshall them. This doesnt work because zusemsg 2.0.0 is final. app2mzs.xsd Changes in Detail : - Add DeliverySystem, ZSDeliveryID and GZ to MessageType (MessageType is the base type of DeliveryResponse.Success, -PartialSuccess, and -Error); Reason: It was added to zusemsg 2.0.0. - Add SignedDeliveryRequestStatus to MessageType. Reason: If msg returns signed reply, this element contains the reply as byte[] such that the signature does not break. - Add optional PreadvicenoteSend to ErrorType (because it was added in zusemsg 2.0.0) - Remove MZSDeliveryID from every instance because this ID does not exist anymore (moa zs does not maintain requests in a database). - Remove DocumentReference from ErrorType as it was removed from zusemsg 2.0.0. - Remove DeliveryConfirmation as node in DeliveryNotificiationType because it does not exist anymore in zusemsg 2.0.0; DeliveryConfirmation is also obsolete because all msg' replies are signed and need to be transferred to the sender application as a byte[], which is done by SignedDeliveryRequestStatus node in MessageType. - Remove DeliveryStatement as node in DeliveryNotificiationType because it does not exist anymore in zusemsg 2.0.0. Other Changes - Adapt codebase: MzsService returns mzs:DeliveryResponse. - Implement conversion from msg:DeliveryRequestStatus to mzs:DeliveryResponse. - Add store / retrieve interface to DeliveryRepository that stores signed delivery request statuses as byte[]. Temporary Changes - Disable integration tests which have external dependencies. [1] https://download.oracle.com/javaee-archive/jaxb.java.net/users/2007/03/6674.html Signed-off-by: Christof Rabensteiner <christof.rabensteiner@iaik.tugraz.at>
2019-05-10Refactor Exception Handling in App2MzsChristof Rabensteiner1-0/+16
- Define dedicated runtime exception - Put AppDeliveryId in exception message