MODEXPW-625 - Enable Email Delivery for EDIFACT Export Jobs#730
Closed
markusweigelt wants to merge 34 commits intofolio-org:masterfrom
Closed
MODEXPW-625 - Enable Email Delivery for EDIFACT Export Jobs#730markusweigelt wants to merge 34 commits intofolio-org:masterfrom
markusweigelt wants to merge 34 commits intofolio-org:masterfrom
Conversation
…ar URL for Feign routing
mod-template-engine returns 400 when outputFormat does not match the format registered in the template. The claims template requires text/html.
Read outputFormat from template-engine response meta and forward it to EmailEntity so the email is sent in the same format the template was rendered in (e.g. text/html).
Wrap templateEngineClient and emailClient calls in EdifactException, derive attachment content type from fileFormat, extract buildAttachment and sendEmail helper methods, and add unit/integration tests for the tasklet and its decider.
Remove template context from TemplateProcessingRequest for now since required template variables are not yet known; mod-template-engine treats a missing context as an empty object. Add ORDERING + EMAIL test coverage.
Migrate EmailClient and TemplateEngineClient from @FeignClient to Spring 6 @HttpExchange. Update Spring Batch import paths to new package structure. Fix SendToEmailTaskletTest to use JobOperatorTestUtils and correct mock types.
…iguration Both clients use @HttpExchange and require explicit @bean registration via HttpServiceProxyFactory — they were missing, causing a NoSuchBeanDefinitionException when sendToEmailStep attempted to inject EmailClient.
Spring HttpServiceProxyFactory requires @RequestBody on POST parameters to resolve them as the request body — unlike Feign which inferred this from unannotated arguments.
…lization RestClient uses Jackson 3 (tools.jackson) which cannot deserialize into the abstract com.fasterxml.jackson.databind.JsonNode (Jackson 2). Return String instead and parse with ediObjectMapper in the tasklet.
…sponse DTO Jackson 3 (RestClient) cannot deserialize JSON into String or the abstract JsonNode (Jackson 2). A concrete DTO is the correct and consistent approach, matching how all other clients in this module handle responses.
Removed the erroneous CLAIMING integration type check; email delivery is driven exclusively by transmissionMethod == EMAIL regardless of integration type. Also added a comment in EdifactExportJobConfig summarising the decider conditions for all three optional steps.
The previous tests checked integrationType alone and had an incorrect PROCESS assertion for FILE_DOWNLOAD. Tests now verify that PROCESS is returned only when transmissionMethod is EMAIL, and SKIP for all other transmission methods.
Introduces validateEmailFields analogous to validateFtpFields, checking emailFrom, emailTo, and emailTemplate when transmissionMethod is Email. Fixes NPE caused by unconditional FTP field validation for Email transmission jobs.
Contributor
|
@SerhiiNosko , could you please assist in review? |
SerhiiNosko
reviewed
Mar 31, 2026
Author
|
@khandramai Currently, some checks in the pipeline are failing because I created the PR from a branch in our organization repository. Should I instead create a branch directly in the module repository and open a new PR there, then close this one - or is it fine as it is? |
Author
|
Recreate the PR #732 using a branch directly in the repository so that the CI runs without failures. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MODEXPW-625
- Send the export by email
Purpose
Introduce Email as a transmission method for EDIFACT export jobs.
When an integration is configured with transmissionMethod: Email, the generated EDIFACT file (e.g., Ordering or Claiming) is automatically sent to the vendor via email.
This allows EDIFACT exports to be delivered directly through email, enabling fully automated email-based ordering and claiming workflows.
Approach
SendToEmailTasklet- reads the generated EDIFACT file from the job execution context, renders subject and body via mod-template-engine (POST /template-request), then delivers the fileas an attachment via mod-email (POST /email)
SendToEmailTaskletDecider- skips the email step unlesstransmissionMethodisEmail; wired intoEdifactExportJobConfigEmailClientandTemplateEngineClienttransmissionMethodisEmailand fails the job early with a clear error if misconfigured