Altova MapForce 2024 Enterprise Edition

Im Beispiel unten sehen Sie die Verwendung von separaten und eingebetteten Signaturen.

 

Separate Signaturen (detached)

Für das Beispielmapping unten wurde die Option Detached (separat) ausgewählt. Es wurden daher zwei separate Dateien generiert: (i) die Mapping-Ausgabe-Datei MarketingExpenses.xml und (ii) eine temporäre Signaturdatei namens MarketingExpenses.xml.xsig (siehe Abbildung unten). Sie finden das Mapping MarketingExpenses_DetachedSignature.mfd im Ordner MapForceExamples.

xmlsig01
xmlsig02

Um .xml- und .xsig-Dateien im Ausgabeverzeichnis zu generieren, klicken Sie auf die Symbolleisten-Schaltfläche Alle generierten Ausgaben speichern ic-save-all-out.

 

Eingebettete Signaturen (Enveloped)

Wenn Sie die Option Enveloped signature (eingebettete Signatur) auswählen, wird das Element <xsig:Signature> nach <expense-item> in die Ausgabedatei integriert (siehe Abbildungen oben). Ein Beispiel für diese Funktion finden Sie in MapForceExamples\MarketingExpenses_EnvelopedSignature.mfd.

 

Gültigkeit des XML-Dokuments

Wenn eine XML-Signatur in das XML-Dokument eingebettet wird, so wird ein Signature Element aus dem Namespace http://www.w3.org/2000/09/xmldsig# zum XML-Dokument hinzugefügt. Damit das Dokument dem Schema gemäß gültig bleibt, muss das Schema die entsprechenden Elementdeklarationen enthalten. Wenn das Schema des XML-Dokuments nicht geändert werden soll, verwenden Sie die Option Detached (siehe oben).

 

In den Codefragmenten unten sehen Sie, wie das Element Signature einer eingebetteten Signatur zulässigerweise verwendet werden kann. Im ersten Codefragment wird das XML-Signatur-Schema in das Schema des Benutzers importiert (gelb markiert).

 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:xsig="http://www.w3.org/2000/09/xmldsig#"
          elementFormDefault="qualified"
          attributeFormDefault="unqualified">
  <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
            schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
  <xs:element name="Root">
     <xs:complexType>
         <xs:sequence>
            <xs:element ref="FirstChildOfRoot"/>
            <xs:element ref="SecondChildOfRoot" minOccurs="0"/>
            <xs:element ref="xsig:Signature" minOccurs="0"/>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
  ...
</xs:schema>

 

Die zweite Möglichkeit ist, ein allgemeines Wildcard-Element hinzuzufügen, das jedes Element aus anderen Namespaces repräsentiert (unten gelb markiert). Wenn Sie das Attribut processContents auf lax setzen, überspringt der Validator dieses Element, da keine übereinstimmende Elementdeklaration gefunden wird. Folglich muss der Benutzer das XML-Signatur-Schema nicht referenzieren. Der Nachteil diese Option ist allerdings, dass an der angegebenen Stelle im XML-Dokument jedes beliebige Element (und nicht nur das Element Signature) hinzugefügt werden kann, ohne dass das XML-Dokument ungültig wird.

 
<xs:element name="Root">
  <xs:complexType>
      <xs:sequence>
         <xs:element ref="selection"/>
         <xs:element ref="newsitems" minOccurs="0"/>
         <xs:element ref="team" minOccurs="0"/>
        <xs:any namespace="##other" minOccurs="0" processContents="lax"/>
      </xs:sequence>
   </xs:complexType>
</xs:element>

 

© 2018-2024 Altova GmbH