Fehlermeldung: 250.002: Cannot sign request: secpkisecapp.o2: 1 documents could not be signed, because the timeout of -1 seconds for waiting for card and PIN has been hit.

Bitte überprüfen Sie, ob die einzelnen Software-Zertifikate für den jeweiligen Benutzer (Konfigurationsdatei "communicationApplicationOSCI.properties" Eintrag key_resource_id_X) korrekt konfiguriert sind. Weiterhin muss das dort konfigurierte Software-Zertifikat korrekt im SecPKI-Server eingerichtet sein.

Ja, das Feld quitt_refmsguuid enthält die UUID der zuvor versendeten Nachricht.

Beispiel: Wird ein BGS mit docId 12345 und NachrichtId 54321 verschickt, so enthält die später empfangene Quittung den im Feld quitt_refmsguuid den Wert 54321.

Die folgende Fehlermeldung besagt, das der Entsorger (Rolle ENT) nicht in der Datei communicationApplicationOSCI.properties (aus dem Ordner /webapps/modawi/WEB-INF/properties/) einkonfiguriert ist und somit die Kommunikation nicht erfolgen kann.

261.012: Fehler bei der OSCI Kommunikation. (Userproperty ABIFA00024, ENT nicht in OSCIProperties gefunden: useOsci: true, intermedUrl: http://vps.zks-mtu.kdo.de/osci-manager-entry/externalentry, intermedCertificate: WEB-INF/properties/vps-pem.cer, User in Properties: ATRIAS0033, ERZ, WEB-INF/properties/22.p12, test22, )

Fehlermeldung:

ModawiException: 001.003: Gewaehlter Schluessel konnte nicht genutzt werden.

Caused by: java.security.InvalidKeyException: Illegal key size or default parameters

Eine Java-Installation hat gewisse Policies. Eine Policy besteht aus Regeln, die jeweils Berechtigungen gewähren. Modawi benötigt mehr Policies als in der Java Standard Installation vorhanden.

Diese Policies finden Sie in dem Ordner jce_policy-6 im Verzeichnis Java6 auf dem Datenträger. Kopieren sie die Dateien des Ordners jce_policy-6 in das Java6-Homeverzeichnis unter \lib\security. (z.B. unter Windows: C:\Programme\Java\jre1.6.0_07\lib\security)

Im "Modawi 2009 Handbuch – Installation" unter dem Abschnitt "3.5.1.1.3 Java-Policies" ist beschrieben, wie Sie diese Ihrem Java hinzufügen können.

Ja, es können mehrere Modawi-Webapplikationen (auch in unterschiedlichen Versionen) auf einem Tomcat laufen.

Dazu müssen zunächst die verschiedenen Modawi-Versionen (auf unterschiedlichen Datenbank-Schemen) installiert und die Namen der in das "webapps"-Verzeichnis zu importierenden WAR's entsprechend angepasst werden, damit im Tomcat mehrere Verzeichnisse angelegt werden.

Anschließend muss im lib-Unterverzeichnis der beiden Modawi-Installationen (also z.B. /WEB-INF/modawi_1/lib/ und WEB-INF/modawi_2/lib/) die Datei bcprov-jdk-<eine versionsnummer>.jar entfernt und einmal in den Shared-Lib-Ordner des Tomcats (/tomcat/lib/) kopiert werden.

Zusätzlich muss noch folgende Änderung in der web.xml der beiden Verzeichnisse vorgenommen werden:

<context-param>
<param-name>webAppRootKey</param-name>
<param-value>modawi.root-1</param-value>
</context-param>

bzw.

<context-param>
<param-name>webAppRootKey</param-name>
<param-value>modawi.root-2</param-value>
</context-param>

Die Datenbanknamen müssen in der documentApplication.properties angepasst werden. Der angegebene Tabellenname ist bei dem Eintrag "persistence.connectUrl" einzutragen.

Die verschiedenen Modawi-Webapplikationen können dann über die Tomcal-URL mit dem entsprechenden WAR-Namen aufgerufen werden. Es bietet sich an, auch die Logausgaben entsprechend aufzuteilen. Die Konfiguration hierfür findet sich in der log4j.properties (Eintrag log4j.appender.logfile.File).

Eine BMU-Quittung ist ein Dokument, das zur Bestätigung des Empfangs einer BMU-Nachricht dient.

Modawi erzeugt die BMU-Quittungen automatisch nach dem Empfang einer Nachricht und bereitet sie für den Versand vor (Status SCHEDULED).  Der Versand erfolgt dann automatisch beim nächsten Aufruf der Methode sendDocuments().

Der ZKSWebService liefert im Fehlerfall eine Quittung mit einer entsprechenden Fehlermeldung.

Bei der Methode retrieveAllAddresses() erstellt Modawi automatisch eine Adressanfrage und Adressanforderung für einen Benutzer. Diese Dokumente werden mit einem im SecPKIServer konfigurierten Software-Zertifikat signiert. Dieses Software-Zertifikat muss für jeden Benutzer in Modawi konfiguriert werden, wobei es das Zertifikat sein muss, mit dem sich der Benutzer bei der ZKS registeriert hat.

Sollte eine falsche Resource-ID (Software-Zertifikat) konfiguriert sein, kann der ZKSWebService keine Zuordnung des Benutzers vornehmen und liefert einen Fehler.

Beim Länder-eANV ist es wie folgt:

Das L-eANV speichert keine Daten. Aus diesem Grund holt es ein Dokument erst dann aus dem VPS-Postfach, wenn der zugehöriger Login-Besitzer es anfordert. Damit er ein Dokument anfordern kann, zeigt ihm das L-eANV diejenigen Dokumente im VPS-Postfach, die aufgrund des Subjects zu dem Login gehören. Dann wird das Dokument erst aus der VPS geholt, dann entschlüsselt und verarbeitet, so dass auch erst dann die BMU-Quittung erzeugt wird.

Die "normalen" Provider oder Modawi arbeiten anders: Sie leeren das eigene Postfach regelmäßig, verarbeiten die enthaltenen Daten direkt und lösen deswegen auch sofort die BMU-XML-Quittung aus.

Modawi 2009 unterstützt die Archivierung der Signaturen in Form der automatisierten Signaturerhaltungslogik des SecPKIServers. Die Archivierung der Dokumente ist mit Hilfe der Registerführung ab der Modawi Version 3.2.11.x möglich. Nähere Informationen zu der Registerfunktionalität befinden sich im "Modawi 2009 Handbuch - Registerfuehrung".

Es gibt in Modawi drei Möglichkeiten, eine Deklarationsanalyse in einen EN einzubinden:

1. als Dateianhang (DADokument/DA/Dateianhang)

Hierbei liegt die Deklarationsanalyse wie im Anhang als eigenständiges Dokument vor und wird mit Hilfe der Methode addAttachment() hinzugefügt.

2. als FreieXMLStruktur (DADokument/DA/FreieXMLStruktur)

Unter einem Knoten mit dem Namen FreieXMLStruktur kann ein beliebiges XML eingefügt werden. Hierzu ist die Methode addXmlArea() zu verwenden.

3. als Deklarationsanalyse (DADokument/DA/Deklarationsanalyse)

Unter dem Knoten Deklarationsanalyse sollen grundsätzlich nur Deklarationsanalysen eingefügt werden, die dem Schema DA_Teil_2_Anhang_E.xsd entsprechen. Es können an dieser Stelle also beispielsweise keine PDF-Dokumente angegeben werden. Wenn Deklarationsanalysen in diesem Schema vorliegen, kann die Deklarationsanalyse über die Felder, die im "Modawi 2009 Handbuch - Feldnamen" beschrieben sind, mit Hilfe der Methode setContent() hinzugefügt werden.

Die Version von Modawi kann aus der MANIFEST-Datei (unter .../modawi/META-INF ) dem Feld "Implementation-Version:" entnommen werden.

Die Version des SecPKIServer kann auf zwei verschiedene Weisen ermittelt werden:

1.

In der Log-Datei des SecPKIServer wird bei Start des Logging die Version des SecPKIServer ausgegeben.

Bei Start eines neuen Log wird in der dritten Zeile des Logs die Version ausgegeben, z.B.:

15.03.2010 10:25:11:793 main: ****************LOGGING IS STARTED****************

15.03.2010 10:25:11:807 main: SecPKI version ID hash 737DECD92B9F566B5019D22C05FE992119740481

15.03.2010 10:25:11:807 main: SecPKI version 4.9.80 Build 3 Patch 3

2.

In der SecPKI-Administrationsanwendung wird in der linken unteren Ecke die Version des SecPKIServer ausgegeben. Siehe Abbildung.

Für den SecSigner ist wichtiger als die Version der Zeitpunkt, zu dem der jeweilige SecSigner zusammengestellt wurde. Daher ist die entscheidende Angabe in der Log-Datei des SecSigner der Zeitpunkt, zu dem die jeweilige Auslieferung signiert wurde.

Z.B.: 16.03.2010 10:10:21:977 main: SecSigner was signed by Heller, Ulrich at Wed Jan 20 13:24:36 CET 2010

Wenn Sie retrieveDocument() aufrufen, bekommen Sie zu jedem empfangenen Dokument folgende Werte (siehe auch Abschnitt 1.3.3.1 im "Modawi 2009 Handbuch - Integration"):

• docId (die ID des importierten Dokuments)
• docType (der Dokument-Typ des importierten Dokuments)
• docState (der Status des Dokuments)
• docStateDetails (weitere Details zum Status)
• docNachrichtUUID (die Dokument-ID der Nachricht)
• docProtocol (das Protokoll, über das das Dokument empfangen wurde)

Ab der Modawi-Version 3.2.11.x erhalten Sie zusätzlich die folgenden zwei Parameter:

• ackNachrichtUUID
• conflictingDocIds

Die Daten über den Sender und Empfänger sind in der Nachricht enthalten. Die Content-Daten einer Nachricht sind über die Methode getContent() mit der docNachrichtUUID als Parameter ermittelbar. Als Rückgabe-Wert erhalten Sie die Content-Daten des Nachrichten-Kopfes. Diese enthalten die Sender- und Empfänger-Daten des Dokuments.

Eine Nachricht ist ein eigenes BMU-Dokument und dient als Container.

Die Nachricht besteht aus Kopfdaten und Nutzdaten. In den Kopfdaten sind Informationen über den Absender und Empfänger der Nachricht enthalten. In den Nutzdaten ist das eigentliche BMU-Dokument.

Jedes BMU-Dokument (mit Ausnahme einer Quittung) wird beim Versenden in eine Nachricht eingebettet. Beim Empfangen (z.B. Methode retrieveDocuments()) wird die UUID der Nachricht des empfangenen Dokuments zurückgegeben. Anhand der UUID kann über die Zugriffsmethode getContent() auf die Kopfdaten der Nachricht zugegriffen werden und eine eventuell eingetragene Antwortadresse ausgelesen werden.

Genauere Informationen sind im "Modawi 2009 Handbuch - Integration" zu finden.