无WSDL的SOAP客户端及SBR（SOAP+ebXML ebms3）技术问询

Hey there! Let's dive into your work with Standard Business Reporting (SBR) using SOAP and ebXML (ebms3), plus tackle those WSDL-less SOAP client questions you have.

First, let's unpack that SOAP envelope snippet you shared. ebMS3 adds structured messaging headers to standard SOAP envelopes to enable reliable, compliant business communication—here's a breakdown of what you're looking at:

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  <soapenv:Header>
    <eb:Messaging xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/" 
                  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
                  soapenv:mustUnderstand="true">
      <!-- ebMS3 messaging content (e.g., UserMessage for payloads, SignalMessage for receipts/errors) will live here -->
    </eb:Messaging>
  </soapenv:Header>
  <soapenv:Body>
    <!-- Your SBR-specific business payload goes here -->
  </soapenv:Body>
</soapenv:Envelope>

Key ebMS3 Header Details: #

• The eb:Messaging element is the heart of ebMS3—it holds critical metadata like message IDs, sender/receiver party info, service/action identifiers, and delivery rules.
• soapenv:mustUnderstand="true" is non-negotiable here—it tells the receiver this header is mandatory to process, which is required for SBR and ebMS3 compliance.
• The wsu namespace links to WS-Security utilities, which you’ll almost certainly need for timestamping, signing, or encrypting messages (essential for maintaining the integrity of SBR reports).

Without a WSDL, you’ll need to construct requests manually based on ebMS3 and SBR specifications. Here’s a practical approach to get you started:

1. Lock in the SOAP Envelope Structure #

• Stick to SOAP 1.2 (since your example uses the 2003/05 soap-envelope namespace).
• Ensure the eb:Messaging header includes all required ebMS3 elements:
  • UserMessage: For sending business payloads—this needs sub-elements like MessageInfo (unique message ID), PartyInfo (sender/receiver details), CollaborationInfo (service/action pairs), and PayloadInfo (links to your SBR data).
  • SignalMessage: For handling acknowledgments, errors, or receipts (critical for reliable messaging in SBR workflows).

2. Manage Namespaces and Payload #

• The SOAP Body will contain your SBR-specific data—double-check you’re using the exact namespaces defined by your organization’s SBR implementation.
• Validate your ebMS3 elements against the official OASIS ebMS3 Core Specification schemas to avoid structural errors.

3. Use HTTP Client Libraries with Manual XML Construction #

• Java: Use HttpURLConnection or Apache HttpClient to send POST requests. You can either build the XML string manually, or generate JAXB classes from ebMS3 XSDs to serialize objects into XML.
• C#: Leverage HttpClient and construct XML with XDocument or XmlDocument. You can also generate strongly-typed classes from ebMS3 XSDs using xsd.exe.
• Python: Use the requests library to send POST requests, and build XML with lxml or the built-in xml.etree.ElementTree.

4. Validate Your Messages #

Even without a WSDL, you can validate your SOAP requests against ebMS3 and SBR schemas. Tools like xmllint (command line) or IDE plugins (e.g., Eclipse’s XML Validator) will help catch namespace mismatches or missing required elements.

5. Handle WS-Security (If Required) #

SBR often requires signed and encrypted messages. For WSDL-less clients, you’ll need to manually add WS-Security headers using libraries like Apache WSS4J (Java) or WSE (C#) to sign the eb:Messaging element and/or your SBR payload.

内容的提问来源于stack exchange，提问作者Darcys22