春季批次异步词标志到下一步
我有两个步骤的工作。 step1最终使用asyncitemwriter写入文件，当我写入文件时，我想检查每个记录是否有任何错误（想象其中带有错误标志的记录对象）。在步骤2中，如果任何先前书面的记录都有错误，则我想将书面文件复制到S3 ELSE删除该书面文件。目前，我将此信息存储在Atomic Boolean实例变量中，在我的AsyncitemWriter中，@AFTERSTEP方法读取该标志并将其燃烧到StepexecutionContext上，并将其用于作业流。我觉得有什么建议，有什么建议吗？
问题的其他信息：
- 我需要处理整个文件，让我的客户知道文件中的所有错误，以便他们可以修复它们并重新上传
- 我正在使用asycnitemprocessor + asyncitemwriter组合的文件中的文件组合
I have two steps job.
Step1 ends up writing to file using AsyncItemWriter, while I am writing to a file I want to check every record if it has any error in it (imagine record object with error flag in it). In step 2, if any of the previously written records has an error in it then I want to copy written file to s3 else delete that written file. Currently I am storing this info in Atomic boolean instance variable in my AsyncItemWriter and the @AfterStep method reading that flag and bubbling it up to the StepExecutionContext and using that in job Flow. I feel like there is a better way for this, any suggestions?
Additional info to the question:
- I need to process entire file and let my clients know all errors in their file so that they can fix them and re-upload the file
- I am using AsycnItemProcessor + AsyncItemWriter combination in Step1
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会在第一个错误上立即失败步骤1，因为无论如何文件都会被丢弃（无需继续读取和处理文件的其余部分）。然后，使用基于步骤1的退出状态的决定者，我将删除文件（Tasklet）或将文件上传到S3（另一个任务）。
编辑：根据评论更新答案
在这种情况下重新上传文件，您可以让步骤1继续直到结束并使用处理器来验证记录并添加每当记录无效时，执行上下文中的信息（验证是项目处理器的典型用例，所以我相信最好将处理器用于项目验证而不是在作者中进行）。基于（即执行上下文），决定者可以决定下一步执行哪个步骤。
I would fail step 1 immediately on the first error, since the file will be discarded anyway (no need to continue reading and processing the rest of the file). Then, with a decider based on the exit status of step 1, I would either delete the file (tasklet) or upload the file to s3 (another tasklet).
Edit: update answer based on comments
In that case, you can let step 1 continue until the end and use a processor to validate records and add the information in the execution context whenever a record is invalid (validation is btw a typical use case of an item processor, so I believe it is better to use a processor for item validation instead of doing it in the writer). Based on that (ie the execution context), the decider can then decide which step to execute next.