Great question—this exact no-mapping, pass-through flow is fully feasible and actually a common optimization when the source system (SAP ECC here) already produces payloads that perfectly match the target’s requirements. I’ve implemented nearly identical setups for tax authority integrations before, so let’s break down how it works and key considerations:

Core Workflow Overview #

The end-to-end flow is straightforward with zero mapping in SAP PI:

1. SAP ECC Side: Your existing tool generates the tax-compliant XML, converts it to a string (or binary XSTRING for large payloads), and calls a custom RFC function to send this string to PI. The RFC also includes an output parameter to receive the tax authority’s response.
2. SAP PI Side: PI acts purely as a router—no message mapping, operation mapping, or payload transformation is needed. It receives the RFC string, forwards it directly as the body of the REST API call to the tax authority, then sends the authority’s response string back to ECC via the RFC’s output parameter.

Step-by-Step Implementation Details #

1. SAP ECC Custom RFC Function #

Create a simple RFC-enabled function module (e.g., Z_TAX_SUBMIT_XML) with:

• Import Parameter: IV_XML_PAYLOAD (type STRING or XSTRING—use XSTRING if your XML exceeds 1MB, since STRING has a 1,048,576 character limit)
• Export Parameter: EV_TAX_RESPONSE (same type as the import parameter to match the response payload)
• Exception Parameters: Add exceptions like PI_COMM_ERROR or TAX_AUTH_ERROR to propagate failure details back to ECC.

2. SAP PI Configuration #

You’ll need a basic integration scenario (using ICOs, CCs, or a classic integration flow—whichever your PI version supports) with:

• Sender RFC Adapter: Point it to your ECC system and the custom RFC function. Ensure it’s configured to pass the payload string as-is without parsing it into an XML structure (this is default behavior for string/XSTRING parameters).
• Pass-Through Integration Flow: Skip all mapping steps. Just route the incoming RFC payload directly to the receiver adapter. No need for message types or data types beyond the basic RFC structures—PI can handle the string payload as a generic message.
• Receiver REST Adapter: Configure it to match the tax authority’s API requirements:
  • Set the correct HTTP method (almost always POST for tax submissions)
  • Define the API endpoint URL
  • Set the Content-Type header to application/xml (to tell the tax authority you’re sending XML)
  • Configure authentication (e.g., Basic Auth, OAuth 2.0) as required by the tax authority
  • Enable response handling so PI captures the authority’s XML response and passes it back to the RFC sender.

Key Considerations to Avoid Pitfalls #

• Payload Size: If your XML is larger than 1MB, use XSTRING instead of STRING in both ECC and PI to prevent truncation. PI’s RFC adapter supports XSTRING natively.
• Encoding Consistency: Ensure ECC generates the XML with the encoding required by the tax authority (usually UTF-8). Configure PI to preserve the encoding during transmission—don’t let PI auto-convert the payload.
• Error Handling: Add logic in your ECC RFC function to check for exceptions and parse the tax authority’s response for error codes. In PI, set up alerting for failed REST calls so you can quickly troubleshoot connectivity issues.
• Testing: Start with a mock tax API (e.g., using a local server or Postman Mock) to validate the end-to-end flow before connecting to the real tax authority. This lets you confirm payloads are passed correctly and responses are routed back properly.

Final Verdict #

This no-mapping approach is not just feasible—it’s efficient, reduces maintenance overhead (since you don’t have to update PI mappings if the tax schema changes, as long as ECC adjusts its XML generation), and aligns perfectly with your existing setup.

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