Signature et ReferencedObject : problème avec signedObjectId

[pibou]

Bonjour,

j'arrive à créer une Signature au sein d'une AU avec des valeurs "en dur" lorsque je renseigne la métadonnée ReferencedObject. Je souhaite passer à des valeurs réelles : les id, digest et algorithm d'un fichier préalablement associé à l'AU à l'aide de addFileSubArchiveUnit.

Je récupère le BinaryDataObject à l'aide de getDataObjectRefList().getDataObjectList() Pour digest et algorithm : pas de soucis, c'est l'id que je ne sais pas comment récupérer. L'uri pourrait me permettre de le reconstituer mais ce champ est généré dynamiquement (appel à toSedaXmlFragments qui relève de la bidouille) et est surtout regénéré lors de la génération du SIP. Pas la bonne voie de toute évidence.

Comment procéder ?

[pibou]

Je suis parti sur une fabrication de mon BinaryDataObject à partir duquel je crée un ReferencedObject à ajouter à mon objet Signature. C'est valide SEDA 2.1 mais la référence utilisée est celle de l'AU et non celle de l'objet binaire, j'utilise en effet docBinaryDataObject.getInDataObjectPackageId() pour initialiser ReferencedObject ...

[pibou]

Ci dessous de nouvelles expérimentations inspirées par l'usage de sedalib dans le projet esup-signature. Conformément au schéma présent dans la doc SEDA, la signature est déportée dans une AU enfant. S'agissant d'une signature intégrée, il n y a qu'un seul binaire.

2 bizarreries :

• id = docBinaryDataObject.getInDataObjectPackageId() est utilisé à la fois pour assigner le binaire à l'AU (addDataObjectById) et pour initialiser le ReferencedObject. Une fois le SIP généré les deux identifiants diffèrent !
• l'identifiant présent dans la Signature après génération du SIP pointe sur l'AU racine. Je m'attendais à une référence à un binaire comme indiqué dans le schéma SEDA

`

        // dans SIP : ID10
        ArchiveUnit seanceAU = sb.createRootArchiveUnit(
                "seance",
                "File",
                "Seance du CA du 32 mai",
                "Conservation des dossiers de séance du Conseil d′Administration");

        // dans SIP : ID11
        ArchiveUnit emargementDossierAu = sb.addNewSubArchiveUnit(
                "seance",
                "dossier emargement",
                "Item",
                "Feuille d’émargement",
                "Une description");

        // dans SIP : ID12
        ArchiveUnit emargementAu = sb.addNewSubArchiveUnit(
                "dossier emargement",
                "emargement",
                "Item",
                "Feuille d’émargement",
                "Une description");
        DataObjectPackage dataObjectPackage = sb.getArchiveTransfer().getDataObjectPackage();
        BinaryDataObject docBinaryDataObject = new BinaryDataObject(
                dataObjectPackage,
                Paths.get("src/main/resources/Procedure/emargement.pdf"),
                "src/main/resources/Procedure/emargement.pdf",
                "BinaryMaster_1");
        docBinaryDataObject.extractTechnicalElements(pl);
        String id = docBinaryDataObject.getInDataObjectPackageId();

        // dans SIP : ID16 (dans Groupe d'objets ID15)
        emargementAu.addDataObjectById(id);
        ReferencedObject referencedObject = new ReferencedObject(
                id,
                docBinaryDataObject.messageDigest.getValue(),
                docBinaryDataObject.messageDigest.getAlgorithm());
        Content emargementAuContent = emargementAu.getContent();
        Signature signature=new Signature();
        // ...

        // dans SIP : ID10 !!!!
        signature.addMetadata(referencedObject);
        emargementAuContent.addMetadata(signature);

`

[pibou]

L'affichage des deux AU document et signature montre qu'avant la génération du SIP, les références sont cohérentes. C'est lors de la génération du SIP et des références que l'ID10 est erronément donné à l'AU racine

`<?xml version="1.0" encoding="UTF-8"?>

ID10 24a001f20fd846e3b978677e8979a0d201e11307b23f3132afc3e19538c44dde14d4d341ad7c6f83faa83366ed5530111e61343bbfd63c90697594ff75ed7be6 ` ` emargement ID10 `

[pibou]

Le problème a été reproduit sur Resip : import d'un SIP On constate que ObjectSignedId référence le bon DataObject "Régénérer des IDs continus" L'ID du dataObject a été modifié, la référence ObjectSignedId est demeurée identique

[pibou]

la méthode regenerateContinuousIds appelée par generateSIP ne gère pas la cohérence entre SignedObjectId et l'identifiant du DataObject référencé. Il est possible de déporter le code, on perd l'appel à verifyContext (privée) qui vérifie la présence des agences.