Batch மட்டும் ஆதரிக்கும் பழைய ERP உடன் SaaS-ஐ எவ்வாறு இணைப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

ERP-இன் batch வரம்புகளை மதிக்கும் **asynchronous, மீட்கக்கூடிய பரிமாற்றத்தை** வடிவமைக்கவும். முதலில் ஏற்கத்தக்க வணிகத் தாமதத்தையும் ஒவ்வொரு data entity-க்கும் உரிய அமைப்பையும் ஒப்புக்கொள்ளுங்கள்; மணிநேர import மீது real-time completion உறுதியளிக்காதீர்கள்.

## கட்டமைப்பும் உரிமையும்

```text
[SaaS API/events] --> [Durable staging] --> [Mapping adapter]
                                               |
                                         [Batch files]
                                               |
                                         [ERP importer]
                                               |
[Status + reconciliation] <------------- [Result files]
```

விற்பனை ஒருங்கிணைப்பு எடுத்துக்காட்டில், சமர்ப்பித்த order request-க்கு SaaS-உம் கணக்கில் பதிந்த financial document-க்கு ERP-உம் உரிமையாளர். அவற்றின் identifiers-ஐ வெளிப்படையாகப் பொருத்துங்கள். Adapter நிலைகள், அலகுகள், புலங்களின் பொருள் ஆகியவற்றை மாற்றுவதால் ERP-க்கே உரிய நடைமுறைகள் SaaS-facing workflow-வில் பரவாது.

## ஒவ்வொரு படியையும் மீட்கக்கூடியதாக்குங்கள்

மூல protocol அனுமதிக்கும் இடங்களில், வந்த வேலையை acknowledge செய்வதற்கு முன் நிலையாகச் சேமியுங்கள். Polling தேவைப்பட்டால், எல்லைப் பதிவுகள் தொலையாதபடி durable checkpoint மற்றும் overlap அல்லது replay விதிகளைப் பயன்படுத்துங்கள். Batch identifiers, record identifiers, schema versions, counts, checksums ஆகியவற்றை வைத்திருங்கள். ஆதரிக்கப்படும் இடங்களில் முழுக் கோப்புகளை atomically வெளியிடுங்கள்; இல்லாவிட்டால் தனி completion marker பயன்படுத்துங்கள்.

ஒவ்வொரு பதிவையும் pending, submitted, accepted அல்லது rejected நிலைகளில் தொடருங்கள். File transfer வெற்றி என்பது business record கணக்கில் பதிந்துவிட்டது என்று அர்த்தமல்ல. ERP முடிவுகளைப் படித்து business identifiers மற்றும் தொகைகளை ஒப்பிட்டுச் சரிபார்க்கவும்; file counts மட்டும் அல்ல. தவறான பதிவுகளைக் காரணங்களுடனும் பொறுப்பான operator-உடனும் தனிமைப்படுத்துங்கள்.

## தெளிவற்ற தோல்வியைக் கையாளுங்கள்

ERP batch-ஐப் பதிந்தும் acknowledgment தொலைந்தால், கண்மூடித்தனமாக மீண்டும் அனுப்புவது business documents-ஐ இரட்டிப்பாக்கலாம். Retry-க்கு முன் ERP ஆதரிக்கும் duplicate key அல்லது query/reconciliation திறனைப் பயன்படுத்துங்கள். இரண்டும் இல்லாவிட்டால், தெளிவற்ற பதிவுகளை controlled reconciliation-க்காக நிறுத்துங்கள்; adapter-side ledger மட்டும் ERP-இல் exactly-once effects-ஐ உறுதிசெய்யாது.

## திறனும் இயக்கமும்

Peak volume மற்றும் outage-க்குப் பிந்தைய மீட்பு உட்பட, ஓர் import window backlog-ஐக் காலிசெய்யுமா என மதிப்பிடுங்கள். Backpressure பயன்படுத்தி, பயனர்களுக்கு உண்மையான காலத்துடன் pending நிலையைத் தெரிவியுங்கள். மிகப் பழைய pending வயது, rejection rate, reconciliation mismatch ஆகியவற்றுக்கு alert அமைக்கவும். Staged files-ஐப் பாதுகாத்து access மற்றும் retention பொறுப்புகளை வரையறுக்கவும்.

## நேர்காணல் அறிகுறி

Consistency boundary மற்றும் recovery process-ஐ விளக்குங்கள். “Queue சேர்க்கவும்” என்பது semantic mapping, partial acceptance அல்லது retries-ஐ deduplicate செய்ய முடியாத ERP-ஐத் தீர்க்காது. வடிவமைப்பு compatibility-க்காக உடனடித்தன்மையை விட்டுக்கொடுக்கிறது; அந்தத் தாமதம் வணிகத்திற்குத் தெரிய வேண்டும்.

மேற்கோள்: [Microsoft: anti-corruption layer](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer).

கட்டமைப்பும் உரிமையும்

ஒவ்வொரு படியையும் மீட்கக்கூடியதாக்குங்கள்

தெளிவற்ற தோல்வியைக் கையாளுங்கள்

திறனும் இயக்கமும்

நேர்காணல் அறிகுறி

தொடர்புடைய கேள்விகள்