De retour de plusieurs éléments de spring batch ItemProcessor

Je suis en train d'écrire un ressort lot et d'emploi dans l'une de mes pas, j'ai le code suivant pour le processeur:

@Component
public class SubscriberProcessor implements ItemProcessor<NewsletterSubscriber, Account>, InitializingBean {

    @Autowired
    private AccountService service;

    @Override public Account process(NewsletterSubscriber item) throws Exception {
        if (!Strings.isNullOrEmpty(item.getId())) {
            return service.getAccount(item.getId());
        }
        //search with email address
        List<Account> accounts = service.findByEmail(item.getEmail());
        checkState(accounts.size() <= 1, "Found more than one account with email %s", item.getEmail());
        return accounts.isEmpty() ? null : accounts.get(0);
    }

    @Override public void afterPropertiesSet() throws Exception {
        Assert.notNull(service, "account service must be set");
    }
}

Le code ci-dessus fonctionne, mais j'ai trouvé qu'il ya des cas où le fait d'avoir plus d'un Account par NewsletterSubscriber est autorisé. J'ai donc besoin de supprimer le contrôle de l'état et de passer plus d'une Account à l'élément de l'écrivain.

Une solution que j'ai trouvé est de changer les deux ItemProcessor et ItemWriter de traiter avec List<Account> type, au lieu de Account mais présente deux inconvénients:

  • Code et des tests sont plus laide et la plus difficile à écrire et à maintenir en raison de listes imbriquées dans writer
  • Plus important à plus d'un Account objet peut être rédigée dans la même transaction car une liste donnée à l'écrivain peut contenir plusieurs comptes et je voudrais éviter cela.

Est-il de toute façon, peut-être l'aide d'un écouteur ou le remplacement de certains composants internes utilisés par spring batch pour éviter les listes de processeur?

Mise à jour

J'ai ouvert une question sur le printemps Jira pour ce problème.

Je suis à la recherche dans isComplete et getAdjustedOutputs méthodes de FaultTolerantChunkProcessor qui sont marqués comme des points d'extension dans SimpleChunkProcessor pour voir si je peux les utiliser d'une certaine façon à atteindre mon objectif.

Tout conseil est le bienvenu.

OriginalL'auteur Fabio | 2014-06-02

  1. 7

    Élément de Processeur prend une chose, et renvoie une liste

    MyItemProcessor implements ItemProcessor<SingleThing,List<ExtractedThingFromSingleThing>> {
    public List<ExtractedThingFromSingleThing> process(SingleThing thing) {
    //parse and convert to list
    }
}

    Envelopper l'aval de l'écrivain de fer. De cette façon, les trucs en aval de cet écrivain n'a pas à travailler avec des listes.

    @StepScope
public class ItemListWriter<T> implements ItemWriter<List<T>> {
    private ItemWriter<T> wrapped;

    public ItemListWriter(ItemWriter<T> wrapped) {
        this.wrapped = wrapped;
    }

    @Override
    public void write(List<? extends List<T>> items) throws Exception {
        for (List<T> subList : items) {
            wrapped.write(subList);
        }
    }
}

    OriginalL'auteur Matt Broekhuis

  2. 3

    Il n'y a pas un moyen de retourner plus d'un point par appel à un ItemProcessor dans Spring Batch sans arriver assez loin dans les mauvaises herbes. Si vous voulez vraiment le savoir, où la relation entre un ItemProcessor et ItemWriter sorties (pas recommandé), jetez un oeil à la mise en œuvre de la ChunkProcessor interface. Alors que le cas simple (SimpleChunkProcessor) n'est pas mauvais en soit, si vous utilisez l'un de la tolérance de panne logique (skip/réessayer via FaultTolerantChunkProcessor), elle est très unwieldily rapide.

    Beaucoup plus simple option serait de passer de cette logique pour un ItemReader qui n'cet enrichissement avant de retourner l'article. Envelopper ce que ItemReader vous utilisez personnalisé dans un ItemReader de mise en œuvre qui fait le service de recherche avant de retourner l'article. Dans ce cas, au lieu de retourner un NewsletterSubscriber du lecteur, vous seriez de retour d'un Account basé sur les informations précédentes.

    Votre réponse est une très bonne option. Cependant j'ai l'impression que la conversion de type appartient à un Processeur et tandis que votre suggestion fonctionne, je vais perdre la chance d'utiliser un SkipListener pour être averti de mauvais éléments d'entrée depuis onSkipInRead a seulement info s'est produite exception et évidemment pas sur l'élément d'entrée qui a causé il.
    J'aime la suggestion de l'habillage du lecteur. Un problème que je peux voir, c'est l'interface du lecteur retourne d'un seul élément, donc si l'OP, lit-on dans un NewsletterSubscriber avec le centre de lecture et les besoins de l'extérieur lecteur à retourner plusieurs Accounts, il ne peut pas les renvoyer tous. Il va devoir gérer le carnet de commandes et de les retourner une à une. Ou ai-je raté quelque chose?

    OriginalL'auteur Michael Minella

  3. 1

    Au lieu de retourner un Compte vous revenez créer un AccountWrapper ou de la Collection. L'Écrivain doit évidemment prendre en compte 🙂

    OriginalL'auteur Esben