An overview of how serialization data flows across pharma systems using HTTPS, SOAP, SFTP, and AS2 to ensure seamless track and trace.Explains why protocol selection directly affects EPCIS transfers, partner connectivity, and compliance.
Data exchange is the foundation of pharma serialization. Every time a system requests serial numbers, sends EPCIS events, communicates with packaging lines, or shares shipment data with partners, it relies on specific communication protocols such as HTTPS, SOAP, SFTP, and AS2. Each of them is designed for specific file sizes, security levels, and operational needs. Yet many serialization issues trace back to simple misunderstandings about how these protocols work. A clear grasp of data exchange fundamentals reduces exceptions, speeds up troubleshooting, and strengthens compliance.
Different Types of Protocols
1. HTTPS (HyperText Transfer Protocol Secure)
HTTPS is a secure version of HTTP that uses TLS encryption to safely exchange data between client and server. In serialization, it is widely used for transactional requests and lightweight data exchange.
How HTTPS Works in Serialization?
- The L4 system sends a request to a whitelisted HTTPS endpoint.
- The destination server validates the request using API keys, OAuth tokens, or client certificates.
- Both sides establish a TLS handshake to encrypt the communication.
- The server returns a synchronous response - meaning the client must wait until the server completes processing.
Technical Considerations
| Technical Consideration |
Details |
| Whitelisting |
- HTTPS endpoints must often be whitelisted in plant networks and firewalls
- Many pharma IT teams use outbound restrictions, so the Track & Trace software’s IP must be explicitly permitted
|
| Timeouts |
- Typical HTTPS timeouts range from 60–240 seconds
- Large EPCIS shipments can exceed this, causing request failures
- Increasing timeouts may violate corporate security policy or conflict with regulatory systems enforcing fixed limits
|
| File Handling |
- HTTPS is suitable for small files (typically <5 MB)
- Larger files require streaming or chunking — which most legacy serialization systems do not support
|
| Acknowledgment |
- HTTPS uses synchronous responses such as 200 OK, 201,400, 500, or vendor-specific status codes
|
2. SOAP (Simple Object Access Protocol)
SOAP is an XML-based message protocol used by many legacy serialization and regulatory systems. It enforces strict schemas, making it popular where structure and validation accuracy are important.
How SOAP Works in Serialization?
- Requests and responses are structured as SOAP envelopes containing XML payloads.
- Validation is enforced using XSD schemas, ensuring messages adhere to exact formats.
- Uses WS-Security:
- XML encryption
- Digital signatures
- Timestamp validation
Technical Considerations
| Technical Consideration |
Details |
| Whitelisting |
- SOAP typically uses HTTPS transport, so endpoint IP ranges must be whitelisted
- Certificates must match expected CN/SAN fields or requests are rejected
|
| Timeouts |
- SOAP servers often enforce stricter processing timeouts because XML parsing is heavy
- Schema validation failures cause immediate SOAP Fault responses
|
| File Handling |
- SOAP is not ideal for file transfer
- Attachments use MTOM or base64 encoding, which increases file size by 30–40%
|
| Acknowledgment |
- SOAP returns detailed Fault codes, providing clarity on validation vs system-level error
|
3. SFTP (Secure File Transfer Protocol)
SFTP is a secure, file-based protocol running over SSH. It is ideal for large EPCIS files, batch events, and asynchronous data exchange.
How SFTP Works in Serialization?
- The L4 system connects to a partner’s SFTP server using a username + SSH key pair.
- Files are uploaded to a specific folder path (e.g., /incoming/epcis/shipments/).
- The receiving system picks up the file asynchronously for processing.
- Processed files are often moved to /archive or /error folders.
Technical Considerations
| Technical Consideration |
Details |
| Whitelisting |
- SFTP requires opening port 22 outbound and whitelisting the partner IP
- SSH fingerprints must be validated before establishing the first connection
|
| Timeouts |
- SFTP avoids synchronous timeouts completely because transfer is asynchronous
- Timeouts only occur if the connection drops due to network instability or inactivity thresholds trigger
|
| Blob Storage |
- Large files (10–200 MB EPCIS shipments) are stored directly as blobs on the SFTP server
- Ideal for event-rich scenarios such as aggregation or large shipment batches
|
| Acknowledgment |
Processing acknowledgment is provided via:
• Auto-generated receipt files
• Status folders (/success, /error)
• Partner callbacks via API
|
4. AS2 (Applicability Statement 2)
AS2 is a B2B communication standard widely used in the US and Indonesia supply chain requirements. It is designed for secure, reliable, file-based data exchange, especially large EPCIS shipment files.
How AS2 Works in Serialization?
- Uses HTTPS + digital certificates to encrypt and sign messages.
- Transmits files (usually EPCIS XML) as MIME payloads.
- The receiver returns an MDN (Message Disposition Notification) to confirm delivery.
- MDN acts as legal proof of transmission, critical for regulated supply chains.
Technical Considerations
| Technical Consideration |
Details |
| Whitelisting |
- AS2 requires whitelisting HTTPS endpoints and ports
- Certificates must be exchanged and configured correctly — mismatches lead to failures
|
| Timeouts |
- AS2 allows asynchronous MDNs, reducing synchronous timeout risk
- Requires stable network and firewall rules for successful delivery
|
| Blob Storage |
- AS2 can handle very large files because processing is asynchronous
- MIME packaging ensures data integrity throughout the transfer
|
| Acknowledgment |
MDNs provide:
• Cryptographic proof of receipt
• Error codes
• Non-repudiation of origin and receipt
|
Advantages & Limitations Overview
| Protocol |
Advantages |
Limitations |
| HTTPS |
- Fast, Real-time communication
- Widely supported across industry
- Flexible authentication mechanisms (OAuth tokens, JWT, Mutual TLS certificates)
- Suitable for low-latency processes
- Low operational overhead
|
- Not reliable for large EPCIS event files due to server timeout limits (commonly 2–4 minutes)
- Even a 99% uploaded file must restart from zero if interrupted
- Both sender and receiver must remain online for the full transaction
|
| SOAP |
- Strong schema enforcement (WS-Security, XML Signatures)
- SOAP Faults provide detailed error messages that simplify troubleshooting
- Supports digital signatures, timestamping, encryption — ideal for compliance-heavy integrations
|
- Heavy, verbose XML increases payload size
- Schema changes require full revalidation and updates
- Nested XML errors are difficult for non-technical users to interpret
- Slower than HTTPS/REST due to XML parsing and signature validation
|
| SFTP |
- Handles very large EPCIS files efficiently
- Resumable transfers if network drops occur
- Works well with asynchronous processing
- Simple folder-based design for easy monitoring, automation, and troubleshooting
- Ideal for high-volume partners
|
- Not suitable for real-time API workflows
- Requires SSH key management and firewall rules
- Needs monitoring to prevent orphaned or partially uploaded files
- No built-in delivery acknowledgment
|
| AS2 |
- Supports signing, encryption, and non-repudiation
- MDNs (Message Disposition Notifications) confirm delivery reliably
- Reliable for large EPCIS payloads
- Designed for secure B2B regulatory environments
|
- Complex to configure (certificates, MDN handling, endpoints)
- Requires dedicated AS2 server infrastructure
- Troubleshooting requires specialized expertise
|
Why HTTPS Fails for Large Size Files?
HTTPS can handle file uploads, but in pharma serialization, it often fails for large EPCIS files due to a combination of architectural, operational, and regulatory constraints.
| Root Cause |
Impact on Serialization Data Exchange |
| 1. Strict timeout limits (60–240s) |
Large EPCIS files exceed processing time → connection drops → retries and failures increase. |
| 2. Synchronous communication requirement |
Both systems must stay connected during full upload + validation → tough for large payloads. |
| 3. No support for resumable uploads |
If upload fails at 99%, it restarts from zero → high bandwidth waste + duplicate attempts. |
| 4. Heavy XML processing overhead |
Large EPCIS XML files take a long time to parse and validate against CBV → higher timeout probability. |
| 5. Regulatory hubs enforce fixed timeouts |
EU Hub, UAE Tatmeen, and others do not allow increasing timeouts → large-file HTTPS submissions are impossible. |
| 6. HTTPS is optimized for APIs, not bulk transfer |
Best suited for small transactional payloads; not for 5–50 MB EPCIS event files. |
Protocol Selection Cheat Sheet
| Activity / Use Case |
Recommended Protocol(s) |
Why This Protocol Works Best |
| Serial number requests (L4 → L3) |
HTTPS, SOAP |
Real-time, low-latency transactional messages. |
| Commissioning / decommissioning events |
HTTPS, SOAP |
Structured, synchronous event updates. |
| EPCIS exchange < 5 MB |
HTTPS |
Fast upload; low overhead; works for small event sets. |
| EPCIS exchange 5–50 MB (typical shipments) |
SFTP, AS2 |
Avoid HTTPS timeouts; reliable for large event files. |
| EPCIS > 50 MB (large aggregations) |
SFTP, AS2 |
Handles heavy payloads; resumable transfers via SFTP; MDN validation via AS2. |
| Regulatory submissions |
SOAP, HTTPS |
Depends on country: EU Hub uses SOAP; some accept HTTPS. |
| B2B supply chain partner exchange |
AS2, SFTP |
Required for DSCSA; ensures encryption, signing, non-repudiation. |
| Bulk data dumps from packaging lines |
SFTP |
Asynchronous, stable for nightly batch uploads. |
| Internal enterprise integrations |
HTTPS / SFTP |
Depends on whether API calls or bulk files are exchanged. |
Conclusion
Data exchange is the plumbing of pharma serialization. Every serial number request, every EPCIS shipment, and every regulatory submission depends on the right protocol being used for the right job. HTTPS brings speed, SOAP brings structure, SFTP brings reliability for large files, and AS2 brings secure B2B delivery with proof of receipt. Understanding these protocols, their limitations, and where they fit ensures fewer exceptions, smoother partner integrations, and more resilient Track & Trace operations. For anyone working across L3, L4, supply chain, or regulatory environments, this knowledge isn’t optional, it’s foundational.
Frequently Asked Questions
1. Why should L4 teams understand these protocols?
Because 70–80% of serialization exceptions stem from misconfigured endpoints, timeouts, incorrect file handling, or protocol mismatches. Understanding right protocols reduces operational hiccups.
2. Why can’t I use HTTPS for all EPCIS submissions?
Because large EPCIS files exceed the processing time of most HTTPS endpoints, causing timeouts. HTTPS is ideal for small, real-time requests, and not for heavy batch uploads.
3. When should I choose SFTP over AS2?
Use SFTP when partners don’t require MDNs or when you want simple, asynchronous large-file transfers. Use AS2 when you need encryption, signing, and formal delivery receipts (common in US DSCSA).
4. What is the safe file size threshold for HTTPS?
Generally under 5 MB for EPCIS XML, depending on system performance and timeout limits. Anything larger should move to SFTP or AS2.
5. Does SFTP support encryption?
Yes. SFTP files are encrypted in transit through SSH, making it secure and widely accepted in regulated industries.
.avif)
.avif)
