diff options
| -rw-r--r-- | docs/changelog.md | 161 | ||||
| -rw-r--r-- | docs/spec.md | 161 | ||||
| -rw-r--r-- | pom.xml | 2 | ||||
| -rw-r--r-- | readme.md | 3 |
4 files changed, 173 insertions, 154 deletions
diff --git a/docs/changelog.md b/docs/changelog.md new file mode 100644 index 0000000..d5d1dcd --- /dev/null +++ b/docs/changelog.md @@ -0,0 +1,161 @@ +# MOA ZS - Changelog + +This document summarizes changes between MOA ZS Releases that were made in the MOA ZS codebase and in the app2mzs interfaces. +For a non-normative summary of changes that were made in the ZUSE specifications (and therefore affect MOA ZS directly and a sender application indirectly), the reader is referred to [ZUSE Specification Changelog](zusespec-changelog.md). + +## Changes MOA ZS 2.0.0 RC6 + +- Bug Fix: Finalize the removal of the "JAXB Class Not Found Exception" workaround from 2.0.0-RC3. +- Bug Fix: Comply with zuse specifications when creating TNVZ / MSG / App Clients (e.g. disable "Store Binary Response" for TNVZ Client and App Client, Disable MTOM for TNVZ Client). +- Refactor: Replace `createSoap1{1,2}` with `create{Tnvz,App,Msg}Client`. +- Change Behavior: In case where MOA ZS receives a notification or request status with a unknown `AppDeliveryID`, MOA ZS issues a warning. + Then, MOA ZS falls back to the default configuration for figuring out on how to handle the notification. + Before, MOA ZS would cancel the process if the `AppDeliveryID` was unknown. +- Bug Fix: Fix NullPointerException when `mzs:DeliveryRequest/Receiver` is identified via `p:IdentificationType`. +- Add `msg:ClearingProfilID` in mzs2msg conversion. + +## Changes MOA ZS 2.0.0 RC5 + +- Bug Fix; Problem: With `perform-query-person-request` activated, MOA ZS generated a `msg:DeliveryRequest` that did not comply with the [msg] schema. Solution: Make response compliant. + +## Changes MOA ZS 2.0.0 RC4 + +- Bug Fix: Ensure that [tnvz] QueryPersonRequest/Sender marshalls correctly (to prevent error 400). + +## Changes MOA ZS 2.0.0 RC3 + +- Remove Workaround that fixes JAXB Class Not Found Exception when running application in Tomcat. +- Bump zusetnvz contracts from version 2.2.006 to 2.2.008. + +## Changes MOA ZS 2.0.0 RC2 + +- Minor Fixes in Documentation and Readme. +- Change MOA ZS Group ID from `at.gv.zustellung` to `at.gv.egiz`. +- Bug Fix: Booleans in [application.yaml](../src/test/resources/config/application.yaml) are parsed correctly. +- Bug Fix: [zusemsg] and [zusetnvz] clients use SOAP 1.2 to comply with the specification. +- Bug Fix: Change `type` property key to `filetype` in [application.yaml](../src/test/resources/config/application.yaml) such that MOA ZS receives the property value. +- Bug Fix: Validation error was assigned to TNVZ Client, but appeared in MSG Client. +- Upgrade [zusemsg] schema files from 2.0.0 to 2.0.007 and apply changes to codebase. +- Upgrade [zusetnvz] from 2.0.0 to 2.0.006 and apply changes to codebase. +- Add licenses, license headers and NOTICE. +- Add @author tags. + +### app2mzs interface changes + +- Switch namespace of `AustrianAdressesOnly` from [tnvz] to [msg]. +- Add new optional element `ClearingProfilID` to `mzs:DeliveryRequestType/Sender`; + Reason: Element was added to [zusemsg] 2.2.007. +- Add new choice in `mzs:DeliveryNotification` to forward new answer of type `msg:ERVConfirmedDelivery` to the app. +- Move element `msg:RelayedViaERV` from `SuccessType` into `MessageType` (so that it's available to all types that derive from `MessageType`). +- Change `mzs:MessageType/ZSDeliveryID` from mandatory to optional element. + Reason: In certain cases the `ZSDeliveryID` does not exist. + Example: Perform QueryPersonRequest, Request fails, no ZSDeliveryID because request was never sent to delivery service. +- Change type of `mzs:Error/Code` from `xs:integer` to `xs:string`. Reason: `msg:Code` is also of type `xs:string`. + +## Changes Between MOA ZS 1.5.3 and MOA ZS 2.0.0 RC1 + +For version 2.0.0, MOA ZS was rewritten from scratch. The following list summarizes the changes: + +- Add compatibility with [zusemsg]. +- Add compatibility with [zusetnvz]. +- Replace the database as persistent storage with an in-memory cache. +- Update the app2mzs WSDL contract and its data types to fit the needs of [zusemsg] and [zusetnvz]. +- Integrate signature verification with MOA SP-SS. +- Drop support for message encryption and signature creation. +- Target Platform Java 12. + +### Changes between app2mzs 1.5.3 and app2mzs 2.0.0 + +This section describes how the app2mzs WSDL contract was changed and explains why these changes were applied. +The changes in the app2mzs WSDL contract accommodate feature additions and feature removals in [zusemsg] 2.0.0 and [zusetnvz] 2.0.0. +Not all changes are backward compatible and require adjustments in app2mzs-1.5.3-compatible clients. + +### Changes in `mzs:DeliveryRequest` + +- The `Server` element was removed from the `DeliveryRequest` type. + In MOA ZS 1.5.3, this element replaced the ZKOPF response. + ZKOPF request and response do not exist anymore, which renders the `Server` response irrelevant. + This change is *not backward compatible*. +- The `ProfileID` option in the `DeliveryRequest/Sender` element was replaced by `msg:SenderProfile` because sender profiles are now registered at the delivery service and referred to via `DeliveryRequest/Sender/SenderProfile`. + This change is *not backward compatible*. +- The `SignatureKeyID` element was removed from `DeliveryRequest` because this element refers to the signing key. + Since signature creation was dropped from MOA ZS, the element is not relevant. + This change is *not backward compatible*. +- The optional elements `msg:Logo` and `msg:AdditionalCriteria` were added to `DeliveryRequest/Sender` because they were also added as optional elements to [zusemsg]. + This change is *backward compatible*. +- The element `Person` in `DeliveryRequest/Sender` was replaced by the `p:CorporateBody` profile because that is the only sender that is allowed by [zusemsg]. + This change is *not backward compatible*. +- `DeliveryRequest/Sender/Address` was removed because the element was dropped in [zusemsg]. + This change is *not backward compatible*. +- An alternative choice to the `Person`-`Address` sequence in `DeliveryRequest/Receiver` was added. + This choice allows to pass a `p:Identification` element instead of the `Person`-`Address` sequence. + The choice was added to enable the optional feature in [zusemsg]. + This change is *backward compatible*. +- The optional element `tnvz:AustrianAddressesOnly` was added to `DeliveryRequest/Receiver` because this element was also added as an optional element to [zusetnvz]. + This change is *backward compatible*. +- The optional element `msg:AdditionalCriteria` and `msg:PreAdviceNote` were added to `DeliveryRequest/Receiver` because these element were also added as optional elements to [zusemsg]. + This change is *backward compatible*. +- The element `MetaData` in `DeliveryRequest` was replaced with the `msg:MetaData` element from [zusemsg]. + The reason for replacing the `MetaData` element is that the `MetaData` from the app2mzs contract represents the same data that the delivery service expects. + Furthermore, the amount of changes between MetaData from app2mzs 1.5.3 and [zusemsg] 2.0.0 prohibits a straight forward conversion between both elements. + This change is *not backward compatible*. +- The optional `Config` element was added to the `DeliveryRequest` element. + This element allows overriding individual configuration parameters for the ongoing request. + This change is *backward compatible*: You do not need to specify any parameters in the `Config`-element since you can also configure delivery requests in [application.yaml](../src/test/resources/config/application.yaml). + See [Chapter Configuration](#configuration) for more details. + +- The element `XMLDocument` was replaced as this element was dropped from [zusemsg] in favor of the `msg:Payload` element. + This change is *not backward compatible*. +- The types `BinaryDocument` and `DocumentReference` in `DeliveryRequest/Payload` were merged to remove duplicated element. Merging these elements ensures that both payload types contain all of `msg:Attachment`s mandatory fields. + This change is *not backward compatible*. +- The element `MD5Checksum` in `DeliveryRequest/Payload/DocumentReference` was replaced with `msg:Checksum`, which was introduced by [zusemsg]. + This change is *not backward compatible*. +- The element `msg:Size` was added to `DeliveryRequest/Payload` because it was also added as a mandatory element in [zusemsg]. This change is not *backward compatible*. +- The `sync` attribute was dropped in favor of the element `Config/ServiceTimeout`. + This change is *not backward compatible*. + +### Changes in `mzs:DeliveryResponse` + +- The option `DeliveryConfirmation` in `DeliveryResponse` was dropped because it was dropped in [zusemsg]. + This change is *not backwards-compatible*. +- Add `DeliverySystem`, `ZSDeliveryID` and `GZ` to `MessageType`, which is the base type of `DeliveryResponse/Success`, -`PartialSuccess`, and -`Error`. + These mandatory elements were added to [zusemsg]. + This change is *backwards-compatible*. +- Add `SignedDeliveryRequestStatus` to` MessageType`. + This optional element contains the original, unaltered response that was sent from the delivery service to MOA ZS. + The app can use this response to verify the contained signature. + This change is *backward compatible*. +- Remove `MZSDeliveryID` because this ID does not exist anymore. + This change is *not backward compatible*. +- Add the optional `PreadviceNoteSent` element to `ErrorType` because it was added in [zusemsg]. + This change is *backward compatible*. +- Remove `DocumentReference` from `ErrorType` because it was removed from [zusemsg]. + This change is *not backward compatible*. +- Add the elements `msg:DeliveryTimestamp` and `msg:RelayedViaERV` to `SuccessType` because they were added in [zusemsg]. + This change is *backward compatible*. + +### Changes in `mzs:DeliveryNotification` + +- Remove `DeliveryConfirmation` and `DeliveryStatement` elements from `DeliveryNotification` as those element were dropped from [zusemsg]. + This change is *not backward compatible*. +- Add the elements `msg:SenderDetails`, `msg:ReceiverDetails`, `msg:User`, `AdditionalFormat` and `msg:NotificationsPerformed` to the `DeliveryNotification` because they were added to [zusemsg]. + This change is *backward compatible*. + +### Changes in `mzs_mypersondata` + +- The element `AbstractPersonType` was defined as `abstract`, since the equivalent type in [zusemsg] is abstract as well. + This change is *not backward compatible*. +- The elements `Name` and `DateOfBirth` in `PhysicalPersonType` were set from optional to mandatory because they are mandatory in [zusemsg]. + This change is *not backward compatible*. +- The optional element `Affix` was added to `PersonNameType` since this element was added to [zusemsg] as well. + This change is *backward compatible*. +- The `CorporateBodyType` was extended by the optional `Target` element that was added to [zusemsg]. + This change is *backward compatible*. +- The elements `FullName` and `Organization` in `CorporateBodyType` were set from optional to mandatory because they are compulsory in [zusemsg]. + This change is *not backward compatible*. +- The restriction from `CountryCode` was lifted. + This change is *backward compatible*. +- The optional attribute `type` was added to `PostalAddressType`. + This change is *backward compatible*. +- The optional attribute `MessengerService` was added to `TelephoneAddressType`. + This change is *backward compatible*. diff --git a/docs/spec.md b/docs/spec.md index 0bdce6f..b4e2f3e 100644 --- a/docs/spec.md +++ b/docs/spec.md @@ -1,5 +1,7 @@ # MOA ZS - Specification +This document gives an overview on what MOA ZS does, on how it can be configured and on which input- and output data MOA ZS processes. + ## Introduction MOA ZS is a web application middleware that allows a sender application (app) to send delivery requests to delivery services. @@ -24,157 +26,6 @@ The following figure shows, with which electronic delivery participants MOA ZS c MOA ZS uses Apache CXF as a web service framework and the Spring Framework as inversion of control container. The application is written in Java and requires JDK 12 as runtime environment. -## Changelog - -This section summarizes changes between MOA ZS Releases that were made in the MOA ZS codebase and in the app2mzs interfaces. -For a non-normative summary of changes that were made in the ZUSE specifications (and therefore affect MOA ZS directly and a sender application indirectly), the reader is referred to [ZUSE Specification Changelog](zusespec-changelog.md). - -### Changes MOA ZS 2.0.0 RC5 - -- Bug Fix; Problem: With `perform-query-person-request` activated, MOA ZS generated a `msg:DeliveryRequest` that did not comply with the [msg] schema. Solution: Make response compliant. - -### Changes MOA ZS 2.0.0 RC4 - -- Bug Fix: Ensure that [tnvz] QueryPersonRequest/Sender marshalls correctly (to prevents error 400). - -### Changes MOA ZS 2.0.0 RC3 - -- Remove Workaround that fixes JAXB Class Not Found Exception when running application in Tomcat. -- Bump zusetnvz contracts from version 2.2.006 to 2.2.008. - -### Changes MOA ZS 2.0.0 RC2 - -- Minor Fixes in Documentation and Readme. -- Change MOA ZS Group ID from `at.gv.zustellung` to `at.gv.egiz`. -- Bug Fix: Booleans in [application.yaml](../src/test/resources/config/application.yaml) are parsed correctly. -- Bug Fix: [zusemsg] and [zusetnvz] clients use SOAP 1.2 to comply with the specification. -- Bug Fix: Change `type` property key to `filetype` in [application.yaml](../src/test/resources/config/application.yaml) such that MOA ZS receives the property value. -- Bug Fix: Validation error was assigned to TNVZ Client, but appeared in MSG Client. -- Upgrade [zusemsg] schema files from 2.0.0 to 2.0.007 and apply changes to codebase. -- Upgrade [zusetnvz] from 2.0.0 to 2.0.006 and apply changes to codebase. -- Add licenses, license headers and NOTICE. -- Add @author tags. - -#### app2mzs interface changes - -- Switch namespace of `AustrianAdressesOnly` from [tnvz] to [msg]. -- Add new optional element `ClearingProfilID` to `mzs:DeliveryRequestType/Sender`; - Reason: Element was added to [zusemsg] 2.2.007. -- Add new choice in `mzs:DeliveryNotification` to forward new answer of type `msg:ERVConfirmedDelivery` to the app. -- Move element `msg:RelayedViaERV` from `SuccessType` into `MessageType` (so that it's available to all types that derive from `MessageType`). -- Change `mzs:MessageType/ZSDeliveryID` from mandatory to optional element. - Reason: In certain cases the `ZSDeliveryID` does not exist. - Example: Perform QueryPersonRequest, Request fails, no ZSDeliveryID because request was never sent to delivery service. -- Change type of `mzs:Error/Code` from `xs:integer` to `xs:string`. Reason: `msg:Code` is also of type `xs:string`. - -### Changes Between MOA ZS 1.5.3 and MOA ZS 2.0.0 RC1 - -For version 2.0.0, MOA ZS was rewritten from scratch. The following list summarizes the changes: - -- Add compatibility with [zusemsg]. -- Add compatibility with [zusetnvz]. -- Replace the database as persistent storage with an in-memory cache. -- Update the app2mzs WSDL contract and its data types to fit the needs of [zusemsg] and [zusetnvz]. -- Integrate signature verification with MOA SP-SS. -- Drop support for message encryption and signature creation. -- Target Platform Java 12. - -### Changes between app2mzs 1.5.3 and app2mzs 2.0.0 - -This section describes how the app2mzs WSDL contract was changed and explains why these changes were applied. -The changes in the app2mzs WSDL contract accommodate feature additions and feature removals in [zusemsg] 2.0.0 and [zusetnvz] 2.0.0. -Not all changes are backward compatible and require adjustments in app2mzs-1.5.3-compatible clients. - -#### Changes in `mzs:DeliveryRequest` - -- The `Server` element was removed from the `DeliveryRequest` type. - In MOA ZS 1.5.3, this element replaced the ZKOPF response. - ZKOPF request and response do not exist anymore, which renders the `Server` response irrelevant. - This change is *not backward compatible*. -- The `ProfileID` option in the `DeliveryRequest/Sender` element was replaced by `msg:SenderProfile` because sender profiles are now registered at the delivery service and referred to via `DeliveryRequest/Sender/SenderProfile`. - This change is *not backward compatible*. -- The `SignatureKeyID` element was removed from `DeliveryRequest` because this element refers to the signing key. - Since signature creation was dropped from MOA ZS, the element is not relevant. - This change is *not backward compatible*. -- The optional elements `msg:Logo` and `msg:AdditionalCriteria` were added to `DeliveryRequest/Sender` because they were also added as optional elements to [zusemsg]. - This change is *backward compatible*. -- The element `Person` in `DeliveryRequest/Sender` was replaced by the `p:CorporateBody` profile because that is the only sender that is allowed by [zusemsg]. - This change is *not backward compatible*. -- `DeliveryRequest/Sender/Address` was removed because the element was dropped in [zusemsg]. - This change is *not backward compatible*. -- An alternative choice to the `Person`-`Address` sequence in `DeliveryRequest/Receiver` was added. - This choice allows to pass a `p:Identification` element instead of the `Person`-`Address` sequence. - The choice was added to enable the optional feature in [zusemsg]. - This change is *backward compatible*. -- The optional element `tnvz:AustrianAddressesOnly` was added to `DeliveryRequest/Receiver` because this element was also added as an optional element to [zusetnvz]. - This change is *backward compatible*. -- The optional element `msg:AdditionalCriteria` and `msg:PreAdviceNote` were added to `DeliveryRequest/Receiver` because these element were also added as optional elements to [zusemsg]. - This change is *backward compatible*. -- The element `MetaData` in `DeliveryRequest` was replaced with the `msg:MetaData` element from [zusemsg]. - The reason for replacing the `MetaData` element is that the `MetaData` from the app2mzs contract represents the same data that the delivery service expects. - Furthermore, the amount of changes between MetaData from app2mzs 1.5.3 and [zusemsg] 2.0.0 prohibits a straight forward conversion between both elements. - This change is *not backward compatible*. -- The optional `Config` element was added to the `DeliveryRequest` element. - This element allows overriding individual configuration parameters for the ongoing request. - This change is *backward compatible*: You do not need to specify any parameters in the `Config`-element since you can also configure delivery requests in [application.yaml](../src/test/resources/config/application.yaml). - See [Chapter Configuration](#configuration) for more details. - -- The element `XMLDocument` was replaced as this element was dropped from [zusemsg] in favor of the `msg:Payload` element. - This change is *not backward compatible*. -- The types `BinaryDocument` and `DocumentReference` in `DeliveryRequest/Payload` were merged to remove duplicated element. Merging these elements ensures that both payload types contain all of `msg:Attachment`s mandatory fields. - This change is *not backward compatible*. -- The element `MD5Checksum` in `DeliveryRequest/Payload/DocumentReference` was replaced with `msg:Checksum`, which was introduced by [zusemsg]. - This change is *not backward compatible*. -- The element `msg:Size` was added to `DeliveryRequest/Payload` because it was also added as a mandatory element in [zusemsg]. This change is not *backward compatible*. -- The `sync` attribute was dropped in favor of the element `Config/ServiceTimeout`. - This change is *not backward compatible*. - -### Changes in `mzs:DeliveryResponse` - -- The option `DeliveryConfirmation` in `DeliveryResponse` was dropped because it was dropped in [zusemsg]. - This change is *not backwards-compatible*. -- Add `DeliverySystem`, `ZSDeliveryID` and `GZ` to `MessageType`, which is the base type of `DeliveryResponse/Success`, -`PartialSuccess`, and -`Error`. - These mandatory elements were added to [zusemsg]. - This change is *backwards-compatible*. -- Add `SignedDeliveryRequestStatus` to` MessageType`. - This optional element contains the original, unaltered response that was sent from the delivery service to MOA ZS. - The app can use this response to verify the contained signature. - This change is *backward compatible*. -- Remove `MZSDeliveryID` because this ID does not exist anymore. - This change is *not backward compatible*. -- Add the optional `PreadviceNoteSent` element to `ErrorType` because it was added in [zusemsg]. - This change is *backward compatible*. -- Remove `DocumentReference` from `ErrorType` because it was removed from [zusemsg]. - This change is *not backward compatible*. -- Add the elements `msg:DeliveryTimestamp` and `msg:RelayedViaERV` to `SuccessType` because they were added in [zusemsg]. - This change is *backward compatible*. - -### Changes in `mzs:DeliveryNotification` - -- Remove `DeliveryConfirmation` and `DeliveryStatement` elements from `DeliveryNotification` as those element were dropped from [zusemsg]. - This change is *not backward compatible*. -- Add the elements `msg:SenderDetails`, `msg:ReceiverDetails`, `msg:User`, `AdditionalFormat` and `msg:NotificationsPerformed` to the `DeliveryNotification` because they were added to [zusemsg]. - This change is *backward compatible*. - -### Changes in `mzs_mypersondata` - -- The element `AbstractPersonType` was defined as `abstract`, since the equivalent type in [zusemsg] is abstract as well. - This change is *not backward compatible*. -- The elements `Name` and `DateOfBirth` in `PhysicalPersonType` were set from optional to mandatory because they are mandatory in [zusemsg]. - This change is *not backward compatible*. -- The optional element `Affix` was added to `PersonNameType` since this element was added to [zusemsg] as well. - This change is *backward compatible*. -- The `CorporateBodyType` was extended by the optional `Target` element that was added to [zusemsg]. - This change is *backward compatible*. -- The elements `FullName` and `Organization` in `CorporateBodyType` were set from optional to mandatory because they are compulsory in [zusemsg]. - This change is *not backward compatible*. -- The restriction from `CountryCode` was lifted. - This change is *backward compatible*. -- The optional attribute `type` was added to `PostalAddressType`. - This change is *backward compatible*. -- The optional attribute `MessengerService` was added to `TelephoneAddressType`. - This change is *backward compatible*. - ## Configuration The folder `src/test/resources/config` serves as a template for configuring MOA ZS. @@ -269,7 +120,13 @@ You may specify if MOA ZS should log events to a file appender via the `logging. You can specify the logging format in `logback.xml`. See [Spring Boot Documentation: Logging](https://docs.spring.io/spring-boot/docs/current/reference/html/howto-logging.html) for further details. -## Namespace Declarations +## MOA ZS Service Documentation + +MOA ZS implements two services: the [app2mzs.wsdl](https://git.egiz.gv.at/moa-zs/tree/src/main/resources/mzs/app2mzs.wsdl) service, which accepts delivery requests from a sender, and the [zuse2app_p2.wsdl](https://git.egiz.gv.at/moa-zs/tree/src/main/resources/zusemsg/zuse2app_p2.wsdl) service, which accepts notifications and request status updates from a delivery service. +The file [app2mzs.xsd](https://git.egiz.gv.at/moa-zs/tree/src/main/resources/mzs/app2mzs.xsd) documents the data structure and the parameters of the [app2mzs.wsdl](https://git.egiz.gv.at/moa-zs/tree/src/main/resources/mzs/app2mzs.wsdl) service. +In order to get a complete overview, you might also review related schema files in the [resources folder](https://git.egiz.gv.at/moa-zs/tree/src/main/resources/). + +### Namespaces MOA ZS and its documentation map the following acronyms to the following namespaces: @@ -5,7 +5,7 @@ <groupId>at.gv.egiz</groupId> <artifactId>moa-zs</artifactId> - <version>2.0.0-RC6-SNAPSHOT</version> + <version>2.0.0-RC6</version> <packaging>war</packaging> <name>Moa ZS</name> @@ -1,7 +1,8 @@ # MOA ZS - README -This file gives instructions on how to build, test, and deploy MOA ZS. +This document gives instructions on how to build, test, and deploy MOA ZS. See [the technical specification](docs/spec.md) for a more detailed description of MOA ZS and how it can be configured. +For changes between release versions (and especially between MOA ZS v1 and MOA ZS v2), see [the changelog](docs/changelog.md). ## Build Instructions |