aboutsummaryrefslogtreecommitdiff
path: root/src/main/java/at/gv/egiz/moazs/preprocess
AgeCommit message (Collapse)AuthorFilesLines
2019-11-29Alter Case Handling "Get Notification where AppDeliveryID is unknown"Christof Rabensteiner2-15/+8
- 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-07Resolve Sonarqube FindingsChristof Rabensteiner1-3/+1
2019-10-04Add Validation for TNVZ QueryPersonRequestChristof Rabensteiner1-0/+6
2019-10-04Add @author Tag Where It Was MissingChristof Rabensteiner5-0/+20
2019-10-04Add Licenses, NOTICE, and License HeaderChristof Rabensteiner5-0/+105
2019-10-02Fix Bug: Replace Boolean.getBoolean with Boolean.valueOfChristof Rabensteiner1-3/+2
- getBoolean:= true if system property exists and is true. - valueOf:= true if parameter == "true" (case insensitive).
2019-09-03Rename MzsClient to AppClientChristof Rabensteiner2-8/+8
...since it's a client that communicates with the app.
2019-08-28Fixes and RefactoringChristof Rabensteiner2-7/+12
- JAXB Hack: Handle InterruptionException properly (as in [1], "Dont swallow Interrupts") - Mzs2MsgConverter: Rename convert(Person) to convertReceiverPerson(Person) to emphasize that this method can only be used to convert Receiver Persons (Reminder: Receiver Persons are PhysicalPersons / CorporateBodies. SenderPersons can also be Authorities) - Mzs2MsgConverter: Remove assertion because not needed anymore. - Refactor: Move mzs:DeliveryRequest validation out ouf augmenter and into service. - Refactor: Create a single entry point for validating a mzs:DeliveryRequest. - Remove unused imports. - Fix log messages. [1] https://www.ibm.com/developerworks/java/library/j-jtp05236/index.html?ca=drs-#2.1
2019-08-28Ensure that Each Step of Each Backend Process is LoggedChristof Rabensteiner1-3/+3
2019-08-20Replace Thread.sleep with AwaitChristof Rabensteiner1-1/+1
2019-08-20Add Custom Http Headers to HTTP ClientsChristof Rabensteiner2-1/+64
- Change app2mzs schema: Add Custom Headers to ClientType Element. - Set custom headers in ClientFactory. - Parse custom headers from spring environment. - Merge custom headers from two different profiles. - Add example to application.yaml. - Test conversion of custom headers from spring profile - Test merging and overriding custom headers.
2019-07-22Test Flow of DeliveryRequest from "End-To-End" & Fix BugsChristof Rabensteiner4-82/+165
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 Rabensteiner1-7/+16
- 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-1/+3
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-19/+75
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 Rabensteiner1-5/+39
- Fix in ConfigUtil: SaveResponseToFile boolean would override LogResponse configuration (Copy Paste Error).
2019-07-12Allow App To Choose Between MsgResponse SinksChristof Rabensteiner1-10/+52
- 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-08Implement Zuse2App ServicesChristof Rabensteiner3-2/+74
- 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-03Refactor: Restructure ProjectChristof Rabensteiner2-8/+8
- Move components that depend on the service contracts into scheme package. - Move cxf related components into util package. - Rename SameThread to SingleThreaded.
2019-07-02Handle tnvz Query Edge Cases by Improving ValidationChristof Rabensteiner3-65/+38
TnvzHelper Fixes - Handle additional edge cases. - Mzs:Schema Change: Eliminate PreAdviceNote redundancy by removing it from mzs:DeliveryRequest/TnvzMetaData; PreadviceNote is already in the Receiver element. Update TnvzHelper accordingly. - Implement and integrate tnvz completeness check into DeliveryRequestAugmenter to ensure that, after augmentation, tnvz can be performed. Refactor mzs:DeliveryRequest Validation: - Before: Validating, merging and generatig ConfigType in ConfigUtil. - Change: Need to add validation of DeliveryRequest (Reason: For performing Tnvz Requests, the DeliveryRequest needs to be in a consistent state). - Problem: DeliveryRequest validation does not fit into ConfigUtil. - Solution: Put validation of DeliveryRequest and Config into new Component "MzsValidation".
2019-07-02Implement And Integrate tnvz:QueryPersonRequest.Christof Rabensteiner1-0/+1
- 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-28Simplified Config ValidationChristof Rabensteiner1-15/+15
- Also: Ensure that truststore is of type JKS because PKCS12 is not supported.
2019-06-27Minor FixesChristof Rabensteiner1-2/+3
2019-06-27Inject Configurable HTTP Policies to MsgClientChristof Rabensteiner1-13/+41
- Refactor: Get rid of MsgClient, because MsgClientFactory can do all the work. - Add Connection Timeout and Request Timeout (Policies of HTTP Client) to mzs:DeliveryRequest/Config and application.yaml. - Update readme: Add JDK 12 Requirement
2019-06-27Fixes; SSL Client Auth Works!Christof Rabensteiner1-0/+10
- Switch to java 12 for now. Reason: Bug [1] in JDK 11 (up to jdk-11+28) impairs SSLHandshake ("Unsupported Operation Exception"), but was fixed in Java 12. - Set HTTP policy to infinite. - Fix key/truststore path resolution - Fix NPE in ConfigUtil.merge - Rearrange application.yaml to include two config profiles (one with and one without SSL for the msg client). - Add key material for testcases (Note: expires: May 2 14:47:08 2020 GMT) - Update MsgClient Testcases [1] https://bugs.openjdk.java.net/browse/JDK-8214098
2019-06-26Protect MsgClient via SSL (ink Client Authentication)Christof Rabensteiner3-40/+168
- 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-16Refactor + Document in preprocessChristof Rabensteiner3-28/+30
- Refactor: Move ConfigType.merge's null check to caller. - Revise documentation of preprocess' public methods.
2019-05-16Document Method in ConfigUtilChristof Rabensteiner1-1/+1
2019-05-16Refactor: Merge Converter, Validator, and Merger into UtilChristof Rabensteiner6-131/+112
- Reason: All three classes opertate with the same data type, have the same clients, and have the same reasons for change. - Makes code in client more readable as it reduces number of dependencies.
2019-05-16Refactor and Test ConfigProfileGeneratorChristof Rabensteiner3-48/+149
Refactor - Add Builder to ConfigProfileGenerator. Reason: Constructor had too many arguments. - Move Conversion from Map to Config from ConfigProfileGenerator into dedicated 'ConvertMapToConfig' Class; Reason: I expect additional configuration properties and I don't want those changes to affect the ConfigProfileGenerator (or it's test cases) - Move Access to Spring's env into facade to simplify ConfigProfileGenerator.
2019-05-15Handle Config Related Edge Cases in Augmenter & ProfileGeneratorChristof Rabensteiner4-22/+99
ConfigProfileGenerator: - Cancel startup if default Config profile is incomplete. - Add property flag 'verify-completeness-of-default-delivery-request-configuration', which allows admin to disable completeness check. In that case, just log a warning if the default profile is incomplete. Augmenter: - Ensure that after merging the config is complete (or throw an exception otherwise). - Refactor: Move ConfigProfileValidator from ConfigProfileGenerator to dedicated "ConfigProfileValidator" class; Reason: Augmenter needs to check completness of at-runtime-compiled configuration. - Refactor: Rewrote code for better readability. Others - NPE Fix in ConfigProfileMerger: If FallbackConfigProfile/Server is empty, use PrimaryProfile/Server.
2019-05-15Refactor ConfigProfileGeneratorChristof Rabensteiner1-16/+29
- Add Source for Code Snippet. - Break down generate() into smaller chunks.
2019-05-15Integrate Config Profiles + RefactoringChristof Rabensteiner3-52/+90
Config Profile Integration: - Merge generated Configs from ConfigProfileGenerator with the default Config; Reason: Merging profile Configs with default Config asap ensures that profile Configs are "as complete as possible" while allowing profile Configs to "on-demand"-override values from the default Config. - Adapt Augmenter to work with Config profiles: Select a Config on the basis of on msg:DeliveryRequest/Config/ProfileId, fall back to 'default' Config. - Schema change: Make ProfileID optional. Refactoring: - Move Config-merging code from Augmenter into dedicated 'ConfigProfileMerger' class. - ConfigProfileGenerator: Clarify stream pipeline and comply with coding standard w.r.t. constant members. - Add Augmenter test cases for profile selection.
2019-05-15WIP: Generate Map of Config Profiles from Spring EnvironmentChristof Rabensteiner2-0/+156
Augmenter - Replace default Config Profile with map of Config Profiles. Now, Augmenter can choose a config profile at runtime and augment it. - Move Augmenter to sub package. WIP - Implement ConfigProfileGenerator, which retrieves Config profiles from Spring Environment and returns an easy-to-use map with profiles that is keyed with profile id's. - Replace application.properties with application.yaml. - Remove Augmenter test cases: They need to be adapted.