Sistem Entegrasyonu: POS, E-ticaret, Banka ve E-fatura Rehberi

Integration Architecture Fundamentals

Integration architecture is the backbone that connects disparate systems

System integration architecture is the technical framework that enables software systems designed to operate independently to share data and processes. This architecture includes these core components:

Architectural Components

• Source systems: Systems that generate data (POS, e-commerce, production)
• Target systems: Systems that consume data (the ERP platform, accounting, reporting)
• Integration layer: Transporting, transforming, and managing data between systems
• Data formats: Standards such as JSON, XML, CSV, EDIFACT
• Communication protocols: HTTP/HTTPS, FTP/SFTP, AS2, AMQP, MQTT

Integration Topologies

1. Point-to-Point

Each system connects directly to another. This is simple for a small number of systems, but management becomes difficult as the number of systems grows. For N systems, N*(N-1)/2 connections are required.

2. Hub-and-Spoke

All systems connect to a central hub (middleware). Management is simplified, but the hub can become a single point of failure.

3. Enterprise Service Bus (ESB)

Provides message routing, transformation, and orchestration via a distributed architecture. It is suitable for large-scale enterprise systems.

4. Event-Driven Architecture (EDA)

Systems publish and subscribe to events. It provides wide-scale scalability and loose coupling.

API Integration: REST, SOAP, GraphQL

APIs are the fundamental building blocks of modern integration

An API (Application Programming Interface) is the interface that allows systems to communicate programmatically. Different API types are suitable for different scenarios:

REST API

Representational State Transfer (REST) is a stateless architecture built on the HTTP protocol. It is the most widely used API type today.

• HTTP methods: GET (read), POST (create), PUT/PATCH (update), DELETE (delete)
• Data format: Usually JSON, sometimes XML
• Advantages: Simplicity, widespread support, easy debugging
• Use cases: E-commerce, mobile applications, SaaS integrations

SOAP API

Simple Object Access Protocol (SOAP) is an XML-based protocol with strict standards. It is still used in enterprise systems and banking.

• Data format: XML (defined by WSDL)
• Security: Advanced security with WS-Security
• Advantages: Transaction support, ACID compliance, strict security
• Use cases: Banking integrations, enterprise ERP systems

GraphQL

A query language and runtime developed by Facebook that allows the client to define the data it needs.

• Feature: Single endpoint, flexible queries
• Advantages: Prevents over-fetching/under-fetching, ease of version management
• Use cases: Modern frontend applications, mobile APIs

API Integration Best Practices

• Always use HTTPS, never HTTP
• Authenticate using API keys or OAuth 2.0
• Prevent abuse by implementing rate limiting
• Ensure backward compatibility with version management (v1, v2)
• Return comprehensive error codes and messages
• Keep API documentation up to date (OpenAPI/Swagger)

Middleware Architecture

Middleware acts as a bridge managing communication between systems

Middleware is the software layer that sits between source and target systems, handling data transformation, routing, and orchestration. Why is it important?

Middleware Advantages

• Loose Coupling: Systems do not need to know each other directly
• Data transformation: Translation between different formats (JSON – XML – CSV)
• Protocol translation: Transition between HTTP – SFTP – AS2 – MQ
• Queue management: Asynchronous processing and load balancing
• Error management: Retry, dead letter queue, circuit breaker
• Monitoring and logging: Centralized observation point

Middleware Types

1. Message Broker

Provides message queue management. Systems produce (producer) and consume (consumer) messages. Examples include Apache Kafka, RabbitMQ, and Azure Service Bus.

2. Enterprise Service Bus (ESB)

Provides message routing, transformation, orchestration, and protocol translation. Examples include MuleSoft, IBM Integration Bus, and WSO2.

3. iPaaS (Integration Platform as a Service)

A cloud-based integration platform. Provides ready-made connectors, visual designers, and managed infrastructure. Examples include Zapier, Make (Integromat), Boomi, and Workato.

Middleware Selection Criteria

• Scale and complexity of your systems
• Technical team competency
• On-premise vs. cloud preference
• Budget and licensing model
• Number and quality of pre-built connectors
• Monitoring and debugging capabilities

Real-time vs. Batch Integration

Choosing the right timing determines integration success

One of the critical decisions in integration architecture is determining when data will be transferred. There are two fundamental approaches:

Real-time Integration

Data is transferred instantly the moment an event occurs.

Advantages:

• Instant data consistency
• Fast business processes
• Improved user experience

Disadvantages:

• Increased system load
• Risk of data loss during target system outages
• More complex error management

Use Cases:

• Instant reflection of POS sales to the ERP platform
• E-commerce order notifications
• Stock level alerts
• Payment processing

Batch Integration

Data is transferred in bulk at specific intervals (hourly, daily).

Advantages:

• Reduces system load
• Error tolerance (retry capability)
• Efficient for large data volumes
• Simpler error management

Disadvantages:

• Data latency
• Temporary inconsistency

Use Cases:

• Daily stock synchronization
• Accounting closing processes
• Reporting data updates
• Master data transfer

Hybrid Approach

Most enterprise systems use both approaches together:

• Critical transactions (orders, payments) are real-time
• High data volumes (reporting, archiving) are batch
• Near real-time is an intermediate solution (e.g., 5-15 minute intervals)

Webhook and Event-Driven Patterns

Webhooks are the primary tool for event-driven integration

A webhook is a mechanism that automatically sends an HTTP POST request to another system when an event occurs in one system. It uses a push model instead of polling.

How Webhooks Work

1. The target system creates a URL (endpoint) and registers it with the source system
2. The defined event occurs in the source system (e.g., a new order)
3. The source system sends an HTTP POST request to the target URL
4. The target system receives the request, processes it, and returns a confirmation (200 OK)

Webhook Advantages

• Resource efficiency: Communication only when an event occurs instead of constant polling
• Instant notification: Real-time integration
• Simplicity: Standard HTTP protocol

Webhook Challenges

• Delivery guarantee: What happens if the target system does not respond?
• Ordering: Do messages arrive in sequence?
• Idempotency: What if the same message arrives multiple times?
• Security: Webhook requests must be verified

Webhook Best Practices

• Use a unique ID for every webhook request (idempotency key)
• Perform webhook verification with an HMAC signature
• Set up a retry mechanism for failed deliveries (exponential backoff)
• Store and monitor webhook logs
• Set timeout durations (e.g., 30 seconds)

Event-Driven Architecture Patterns

Event Sourcing

State changes are recorded as events. The current state is derived from the replay of events. Ideal for audit trails and temporal queries.

CQRS (Command Query Responsibility Segregation)

Read and write operations use separate models. Provides performance optimization and scalability.

Saga Pattern

Distributed transaction management. Used for consistency in microservices architecture.

EDI Standards and Use Cases

EDI is an important part of B2B integrations

EDI (Electronic Data Interchange) is a system that enables the exchange of electronic documents in a standard format between business partners. It is a technology that existed before modern APIs but remains critically important.

EDI Standards

EDIFACT (UN/EDIFACT)

An international standard developed by the United Nations. Common in European and international trade.

X12 (ANSI ASC X12)

A standard widely used in North America. Dominant in the US retail and healthcare sectors.

TRADACOMS

An older standard used in the UK retail sector.

Common EDI Document Types

• Purchase Order (ORDERS / 850): Purchase order
• Order Response (ORDRSP / 855): Order confirmation
• Shipping Notice (DESADV / 856): ASN (Advanced Shipping Notice)
• Invoice (INVOIC / 810): Commercial invoice
• Inventory Report (INVRPT / 846): Inventory status

EDI Communication Protocols

• AS2 (Applicability Statement 2): Secure EDI transfer over HTTP
• SFTP: Secure file transfer
• VAN (Value Added Network): Third-party EDI networks
• AS4: Modern alternative based on web services

EDI vs. API: Which and When?

• Choose EDI: Mandatory standards with large retail chains, logistics firms, and B2B partners
• Choose API: Modern SaaS integrations, flexible data needs, rapid development
• Hybrid approach: EDI for EDI partners, APIs for modern systems

Field Example: Omnichannel Retail Integration

Real Case (Unbranded)

Situation

A 45-branch retail chain. 8 different systems to be integrated: Central ERP, 3 different POS brands, e-commerce platform, bank POS, e-invoice service, logistics partner. Daily transaction volume: 15,000+ sales.

Integration Architecture Decisions

1. Middleware selection: iPaaS solution chosen (ready-made connectors, visual design, managed infrastructure)
2. POS integration: Real-time API for data transfer to ERP at the moment of sale
3. E-commerce: Order notification via webhook, stock synchronization via batch (15-minute intervals)
4. Bank: Reconciliation via SOAP API, daily transfer to ERP via batch
5. E-invoice: Invoice creation and submission via real-time API
6. Logistics: Shipment notification via EDI (DESADV)

Result (Representative)

• Integration setup time: 12 weeks
• Daily transaction success rate: 99.7%
• Average data latency: POS-ERP 3 seconds, e-commerce stock 12 minutes
• Reduction in manual data entry: 85%
• Reconciliation time: Reduced from 2 business days to 2 hours

7 Most Common Mistakes in Integration Architecture

1. Failing to Plan for Error Scenarios

The assumption that “the system always works.” There is no plan for target system outages, network errors, or timeouts. Data is lost or remains inconsistent.

2. Not Ensuring Idempotency

Duplicate records are created when the same message is processed multiple times. For example, the same order is written to the ERP twice. Every message must have a unique ID and be checked for duplicates.

3. Insufficient Logging and Monitoring

Integration errors are only noticed when users complain. There is a lack of proactive monitoring, alerts, and dashboards. Troubleshooting takes hours.

4. Tight Coupling

Systems are directly dependent on each other. A change in one system affects all integrations. Connections are made without a middleware or abstraction layer.

5. Neglecting Security

API keys are stored in code, HTTP is used instead of HTTPS, and authentication is weak. Risks of data leakage and unauthorized access are ignored.

6. Lack of Documentation

Integration flows, data mapping rules, and error codes are not documented. Knowledge loss and maintenance difficulties occur during developer turnover.

7. Going Live Without a Test Environment

Integrations are tested directly in the production environment. Errors affect real data, and rolling back is difficult and costly.

Careful planning prevents errors

Error Management and Retry Strategies

Errors are inevitable in integration systems. What matters is establishing mechanisms that render errors harmless.

Retry Strategies

1. Fixed Interval

The same amount of time is waited after each failed attempt (e.g., 30 seconds). Simple, but can strain the target system.

2. Exponential Backoff

The waiting time increases exponentially with each attempt (1s, 2s, 4s, 8s…). Gives the target system breathing room.

3. Exponential Backoff + Jitter

Random variation is added to the waiting time. Prevents a large number of clients from retrying simultaneously.

Circuit Breaker Pattern

If the target system consistently returns errors, it temporarily stops requests:

• Closed: Normal operation, requests are passed through
• Open: Error threshold exceeded, requests are blocked
• Half-Open: Test requests are sent, recovery is checked

Dead Letter Queue (DLQ)

Messages for which all retry attempts fail are moved to a separate queue (DLQ). These messages are:

• Held for manual review
• Subjected to recovery processes
• Stored for analysis

Idempotency

Executing the same transaction multiple times should not change the result. How is it ensured?

• A unique ID (UUID) is assigned to every message
• The ID is checked before processing
• If it has already been processed, the result is returned directly

Monitoring and Alert Systems

Integration systems must be monitored 24/7. Problems should be detected before users notice them.

Metrics to Monitor

Transaction Metrics

• Total transaction count (by minute/hour/day)
• Success/failure transaction ratio
• Average transaction duration (latency)
• Queue depth

System Metrics

• CPU, memory, disk usage
• Network I/O
• Connection pool status

Business Metrics

• Number of processed orders/invoices
• Data consistency ratios
• SLA compliance rates

Alert Strategy

• Critical (P1): Transaction success rate dropped below 95% – instant notification
• High (P2): Latency is 2x normal – notification within 15 minutes
• Medium (P3): Accumulated messages in DLQ – hourly summary
• Low (P4): Capacity warnings – daily report

Dashboards and Visualization

Create dashboards where integration health can be seen at a glance:

• Traffic map (which systems are talking)
• Error distribution (by system, type, time)
• Trend graphs (transaction volume, error rate)
• SLA tracking table

Integration Success Metrics

The following metrics can be used to evaluate the health of the integration architecture (representative values):

Integration Architecture Checklist

For a custom integration architecture design for your project, you can reach out via the contact page.

Frequently Asked Questions (FAQ)