moa-zs - Middleware that allows a sender application to send delivery requests to delivery services

Age	Commit message (Collapse)	Author	Files	Lines
2020-03-03	Update Copyright to 2020	Christof Rabensteiner	1	-1/+1

2019-11-29	Refactor & Fix Client Creation in Client Factory	Christof Rabensteiner	1	-1/+1
	- 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-30	Refactor: Rename ClientFactory.create Interface	Christof Rabensteiner	1	-1/+1
	- Reason: Consistency
2019-10-04	Add @author Tag Where It Was Missing	Christof Rabensteiner	1	-0/+4

2019-10-04	Add Licenses, NOTICE, and License Header	Christof Rabensteiner	1	-0/+21

2019-10-02	For {TNVZ, MSG}: Switch to Soap 1.2	Christof Rabensteiner	1	-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-03	Rename MzsClient to AppClient	Christof Rabensteiner	1	-1/+1
	...since it's a client that communicates with the app.
2019-08-28	Ensure that Each Step of Each Backend Process is Logged	Christof Rabensteiner	1	-0/+6

2019-07-16	Implement ForwardResponseToService Sink And All Its Implications	Christof Rabensteiner	1	-0/+33
	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.