7
votes

Données de routage vers plusieurs fichiers dans l'item Writer en fonction de la propriété de l'article en tant que critère

Je reçois une liste d'articles dans mon lecteur.

Il existe une propriété appelée code dans chaque objet d'élément ayant plusieurs valeurs possibles non connues de moi avant la main.

1) Basé sur la valeur du code dans chaque élément, je veux écrire cet élément particulier dans un fichier de sortie relatif à ce code . Par ex. Si de mon élément actuel est "ABC", l'élément doit être écrit dans ABC.TXT dans l'auteur.

2) S'il y a un code "xyz" dans l'élément actuel, pour lequel le fichier n'est pas présent, un nouveau fichier doit être créé et l'élément doit aller dans ce fichier.

3) Pour tous ces fichiers multiples créés en fonction du code , je souhaite également ajouter un en-tête et un pied de page de page de page pour entrer quelques détails par exemple. Compte d'éléments dans chaque fichier.

est-il possible d'avoir un écrivain qui satisfait au-dessus de 3 exigences?

Je sais que l'utilisation de MultiSourceItemwriter, on peut diviser les données entre plusieurs fichiers de sortie. Mais autant que je sache, cette division est basée sur le nombre d'articles. Par ex. 10 premiers articles dans File1, 10 suivants dans File2 et ainsi de suite.

Mais comment acheminer des données pour produire des fichiers en fonction d'une propriété d'article comme mentionné dans ma question?

Je connais bien avec le lot de printemps et j'ai juste besoin d'un peu de conseils car c'est la première fois que je suis confronté à ce type de problème.

Merci de la lecture!


3 commentaires

Combien d'articles attendez-vous par fichier (maintenant et sur la durée de vie du produit)


@Michaellange: Les informations que j'ai dans ma main en ce moment, je crois que ce serait autour des enregistrements de lakh par fichier.


@Michaellange: cent mille enregistrements par fichier :)


6 Réponses :


0
votes

Une autre option serait de construire 3 listes contenant les éléments séparés par leur code. Ensuite, utilisez une étape différente pour écrire ces listes au système de fichiers.

Un avantage est que vos éléments sont prêts à être écrits, vous pouvez donc utiliser un grand tampon pour augmenter votre écriture de débit (en fonction de votre matériel bien sûr).

Si le nombre de fichier que vous devez générer est dynamique, je vous suggère de les écrire de manière séquentielle pour éviter tout problème de multithreading.

Vous ne pouvez pas rouler de manière dynamique des éléments. Donc, l'idée est de créer une liste d'éléments acheminés par vous-même, puis de travailler sur ces listes.


0 commentaires

9
votes

Si je comprends votre problème correctement, vous avez besoin de quelques articles.

premier, un classificateur qui implémente le classificateur interface xxx

second une implémentation de routeur qui consomme la méthode ci-dessus < Pré> xxx

et dernier de tous, a classificateurcositeItemWiter xxx

n'a pas compilé ce qui précède mais espère que cela aide.


2 commentaires

Je ne peux pas utiliser votre solution car votre solution suppose intrinsèquement que le nombre d'écrivains en sont nombreux. Mais dans mon problème, je ne connais pas le nombre et le type d'écrivains avant la main et je ne peux donc pas définir Abcitemwriter / XyzitemWritre avant la main.


Vous auriez besoin d'écrivains dynamiques. ItemReaders et itacriers sont construits avant la démarrage de l'étape, donc je doute que le lot de printemps puisse gérer cela.



1
votes

Je l'essayerais avec au moins 2 stratégies

  1. Le lot écrit toutes les données dans une table de base de données temporaire et un outil simple / lot / script crée les fichiers individuels - je ne suis pas sûr de l'en-tête / le pied de page, mais comme toujours, on pouvait dire "le gardons pas cher"
  2. Le véritable écrivain crée et gère les écrivains nécessaires à la volée, peut-être avec un écrivain / haricot pré-configuré abstrait comme modèle, tant que vous ignorez les scénarios de redémarrage qu'il sonne "facile"

1 commentaires

Stackoverflow.com/users/887235/vicky @vicky Pouvez-vous mettre votre implémentation à titre de référence!



-2
votes

J'ai rencontré ce même problème ce matin. Enfin, j'ai trouvé que l'actuellement classificateurCommositeItemwrtretre ne prenne pas la priorité à FlatfileItemwrtret comme téméraire de délégué à la dernière version 2.1.9 de Spring Batch.

WriternotopenException est jeté comme ci-dessous: P>

org.springframework.batch.item.WriterNotOpenException: Writer must be open before it can be written to
    at org.springframework.batch.item.file.FlatFileItemWriter.write(FlatFileItemWriter.java:236)
    at org.springframework.batch.item.support.ClassifierCompositeItemWriter.write(ClassifierCompositeItemWriter.java:65)
    at org.springframework.batch.core.step.item.SimpleChunkProcessor.writeItems(SimpleChunkProcessor.java:171)
    at org.springframework.batch.core.step.item.SimpleChunkProcessor.doWrite(SimpleChunkProcessor.java:150)
    at org.springframework.batch.core.step.item.SimpleChunkProcessor.write(SimpleChunkProcessor.java:269)
    at org.springframework.batch.core.step.item.SimpleChunkProcessor.process(SimpleChunkProcessor.java:194)
    at org.springframework.batch.core.step.item.ChunkOrientedTasklet.execute(ChunkOrientedTasklet.java:74)
    at org.springframework.batch.core.step.tasklet.TaskletStep$ChunkTransactionCallback.doInTransaction(TaskletStep.java:386)
    at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
    at org.springframework.batch.core.step.tasklet.TaskletStep$2.doInChunkContext(TaskletStep.java:264)
    at org.springframework.batch.core.scope.context.StepContextRepeatCallback.doInIteration(StepContextRepeatCallback.java:76)
    at org.springframework.batch.repeat.support.RepeatTemplate.getNextResult(RepeatTemplate.java:367)
    at org.springframework.batch.repeat.support.RepeatTemplate.executeInternal(RepeatTemplate.java:214)
    at org.springframework.batch.repeat.support.RepeatTemplate.iterate(RepeatTemplate.java:143)
    at org.springframework.batch.core.step.tasklet.TaskletStep.doExecute(TaskletStep.java:250)
    at org.springframework.batch.core.step.AbstractStep.execute(AbstractStep.java:195)
    at org.springframework.batch.core.job.SimpleStepHandler.handleStep(SimpleStepHandler.java:135)
    at org.springframework.batch.core.job.flow.JobFlowExecutor.executeStep(JobFlowExecutor.java:61)
    at org.springframework.batch.core.job.flow.support.state.StepState.handle(StepState.java:60)
    at org.springframework.batch.core.job.flow.support.SimpleFlow.resume(SimpleFlow.java:144)
    at org.springframework.batch.core.job.flow.support.SimpleFlow.start(SimpleFlow.java:124)
    at org.springframework.batch.core.job.flow.FlowJob.doExecute(FlowJob.java:135)
    at org.springframework.batch.core.job.AbstractJob.execute(AbstractJob.java:281)
    at org.springframework.batch.core.launch.support.SimpleJobLauncher$1.run(SimpleJobLauncher.java:120)
    at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:48)
    at org.springframework.batch.core.launch.support.SimpleJobLauncher.run(SimpleJobLauncher.java:114)


3 commentaires

Quelle est la solution alors?


hi @ user2228932 Je reçois aussi la même erreur .. Avez-vous eu une solution pour cela?


Implémentation d'éléments d'éléments et remplacer la méthode ouverte



3
votes

Sous la solution travaillée pour moi. Compilé le code et ça marche bien.

Premièrement, vous aurez besoin d'un classificateur. Soit implémenter l'interface classifieur ou l'annotation de la méthode classifiée () avec @Classifificateur. P>

Ici, j'ai utilisé Annotation. P>

<batch:step id="step1">
    <batch:tasklet>
        <batch:chunk reader="reader" processor="processor" writer="ItemWriter" commit-interval="3">
            <batch:streams>
                <batch:stream ref="pol01ItemWriter"/>
                <batch:stream ref="pol02ItemWriter"/>
            </batch:streams>
        </batch:chunk>
    </batch:tasklet>
</batch:step>


0 commentaires

0
votes

java config pour JDBC Writer

Voici comment je l'ai fait pour JDBC Writer. Nous pouvons avoir une configuration similaire pour le rédacteur en flèche xxx


0 commentaires