MODEXPW-625 - Enable Email Delivery for EDIFACT Export Jobs#732
Open
markusweigelt wants to merge 43 commits into
Open
MODEXPW-625 - Enable Email Delivery for EDIFACT Export Jobs#732markusweigelt wants to merge 43 commits into
markusweigelt wants to merge 43 commits into
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.
… shared steps Move shared step and decider dependencies from method parameters to @lazy constructor-injected fields, reducing constructEdifactExportJob from 8 to 3 parameters. Also update folio-export-common submodule and remove unused fileName parameter from SendToEmailTasklet.resolveTemplate.
…nMethod is not FTP The decider previously always executed the FTP step for ORDERING integration type regardless of transmissionMethod, causing an NPE when ediFtp config is absent (e.g. Email-only exports).
…bean ambiguity Spring 6.1+ no longer retains parameter names by default, so @lazy Step injection matched all 14 Step beans instead of the intended one.
Constructor injection with @Lazy/@qualifier fails for same-class @bean definitions due to circular dependencies and Spring 6.1 parameter name retention changes. Revert to the original pattern of passing shared steps as @bean method parameters.
# Conflicts: # folio-export-common
Author
|
@folio-org/firebird-backend Does this PR need a review? Right now, the CI pipeline looks good, and it could be merged without an additional approval. What do you mean? fyi We're still new to FOLIO, so any pointers on the usual process would be appreciated. |
markusweigelt
force-pushed
the
MODEXPW-625
branch
from
e69e3bf to
76eb73d
Compare
|
markusweigelt
force-pushed
the
MODEXPW-625
branch
from
292e6a5 to
76eb73d
Compare
|
|
SerhiiNosko
reviewed
Jun 9, 2026
| import org.springframework.batch.core.job.JobExecution; | ||
| import org.springframework.batch.core.step.StepExecution; | ||
|
|
||
| import static org.folio.dew.domain.dto.VendorEdiOrdersExportConfig.IntegrationTypeEnum.CLAIMING; |
Contributor
There was a problem hiding this comment.
CLAIMING import is not used now, so can be deleted
SerhiiNosko
reviewed
Jun 9, 2026
| @@ -0,0 +1,30 @@ | |||
| { | |||
Contributor
There was a problem hiding this comment.
there is no references to this file in tests, so please add new test or delete this file
SerhiiNosko
reviewed
Jun 9, 2026
Contributor
There was a problem hiding this comment.
do not forget after merging folio-export-common PR to master to change reference here to master commit instead of fork commit
SerhiiNosko
reviewed
Jun 9, 2026
| private DefaultFolioExecutionContext buildFolioExecutionContext(Map<String, Object> messageHeaders) { | ||
| var baseContext = DefaultFolioExecutionContext.fromMessageHeaders(folioModuleMetadata, messageHeaders); | ||
| log.info("buildFolioExecutionContext:: configured okapiUrl='{}', baseContext.okapiUrl='{}'", | ||
| okapiUrl, baseContext.getOkapiUrl()); |
Contributor
There was a problem hiding this comment.
and okapiUrl from kafkaHeaders does not work?
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
2 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