Bakıda ERP inteqrasiya hazırlanması yalnız sistemləri API ilə bir-birinə qoşmaq deyil. Əsas məqsəd satış, müştəri, məhsul, stok, hesab-faktura və çatdırılma məlumatlarının hər biri üçün etibarlı sahib sistemi müəyyən etmək, dəyişiklikləri lazımi vaxtda ötürmək və eyni əməliyyatın ikinci dəfə yaranmasının qarşısını almaqdır. Əks halda şirkət daha çox proqramdan istifadə edir, lakin yenə də Excel faylları, telefon zəngləri və əl ilə düzəlişlərdən asılı qalır.
ERP inteqrasiyası adətən CRM-də yaradılan müştəri və sifarişin ERP-yə keçməsini, ERP-də təsdiqlənən qiymət və maliyyə statusunun satış komandasına qayıtmasını, anbar qalığının e-ticarət vitrininə verilməsini və çatdırılma statusunun müştəriyə görünməsini əhatə edir. Bu axınların hamısını “iki tərəfli sinxronizasiya” kimi təsvir etmək kifayət deyil. Hər obyekt, hər status keçidi və hər istisna üçün dəqiq qayda tələb olunur.
İnteqrasiyadan əvvəl hər qeyd üçün sahib sistemi müəyyən edin
İnteqrasiya layihələrinin ən bahalı problemi çox vaxt API deyil, ziddiyyətli məlumatdır. Məsələn, satış meneceri CRM-də müştərinin telefonunu yeniləyir, mühasibat komandası isə ERP-də hüquqi adını dəyişir. Hər iki sistem bütün müştəri profilinin sahibi kimi davranarsa, son sinxronizasiya digər dəyişikliyi silə bilər.
Buna görə texniki iş başlamazdan əvvəl “sahiblik matrisi” hazırlanmalıdır. Matris hər obyekt üzrə bu suallara cavab verir:
- Müştəri: hüquqi rekvizitlərin, satış əlaqəsinin və çatdırılma ünvanının sahibi hansı sistemdir?
- Məhsul: SKU, barkod, vahid ölçüsü, maya dəyəri və satış təsviri harada idarə olunur?
- Qiymət: standart qiymət, B2B endirimi, valyuta və vergi qaydası hansı sistemdən gəlir?
- Sifariş: sifarişin ilkin yaradılması, təsdiqi, ləğvi, qismən göndərişi və geri qaytarılması harada qeydə alınır?
- Stok hərəkəti: rezervasiya, anbarlararası transfer, sayım fərqi və silinmə hansı sistemdə etibarlıdır?
- Maliyyə sənədləri: hesab-faktura, ödəniş, kredit notu və borc qalıqlarının yekun mənbəyi hansıdır?
Praktik yanaşma “bir obyekt — bir əsas sahib” prinsipidir. Bununla yanaşı, atribut səviyyəsində sahiblik də mümkündür: məsələn, ERP məhsulun maliyyə və stok sahələrinin, e-ticarət platforması isə marketinq təsvirinin sahibi ola bilər. Belə hallarda inteqrasiya bütün qeydi kor-koranə əvəz etməməli, yalnız sahibi olduğu sahələri yeniləməlidir.
Real vaxt, hadisə əsaslı və planlı sinxronizasiya arasında düzgün seçim
Hər məlumatın saniyələr içində ötürülməsi nə həmişə lazım, nə də faydalıdır. Real vaxt inteqrasiyası API sorğusu, webhook və ya növbəyə yazılmış hadisə ilə işləyə bilər; planlı sinxronizasiya isə müəyyən intervalda dəyişən məlumatları toplayır. Microsoft-un inteqrasiya memarlığı üzrə tövsiyələrində də real vaxt üçün API/webhook və mesajlaşma, böyük və gecikməyə dözümlü məlumatlar üçün isə fon tapşırıqları və batch ötürmələri fərqləndirilir.
Real vaxt axınları üçün uyğun nümunələr
- Onlayn sifariş verildikdə stokun rezervasiyası;
- Ödəniş statusunun sifarişə tətbiqi;
- Çatdırılma xidməti tərəfindən kuryerə təhvil statusunun qaytarılması;
- Kredit limiti və ya bloklanmış müştəri yoxlaması;
- Qiyməti yüksək olan məhsulun artıq satılmasının qarşısını almaq.
Planlı və ya batch sinxronizasiya üçün uyğun nümunələr
- Gecəlik məhsul kataloqu və qiymət yenilənməsi;
- Tarixi satışların ilkin miqrasiyası;
- Gündəlik maliyyə üzləşdirməsi;
- Çox sayda filial üzrə stok qalıqlarının yoxlanması;
- ERP-nin yalnız məhdud vaxtlarda əlçatan olan köhnə API-si ilə iş.
Seçim “real vaxt daha müasirdir” düşüncəsinə əsaslanmamalıdır. Biznes sualı belə olmalıdır: bu məlumat 5 dəqiqə geciksə, yanlış qərar, artıq satış, maliyyə riski və ya müştəri narazılığı yaranacaqmı? Cavab yoxdursa, sadə, izlənən və təkrar işlədilə bilən planlı sinxronizasiya daha münasib ola bilər.
Dublikat müştəri, sifariş və stok hərəkətlərinin qarşısını necə almaq olar
Dublikatlar adətən şəbəkə kəsintisi, vaxt limiti, webhook-un təkrar göndərilməsi və ya istifadəçinin eyni əməliyyatı iki dəfə etməsi ilə yaranır. Məsələn, satış sistemi ERP-yə “sifariş yarat” sorğusu göndərir, lakin cavab gəlməzdən əvvəl bağlantı kəsilir. Sorğunu sadəcə yenidən göndərmək ERP-də ikinci sifariş yarada bilər.
Bunun qarşısı üçün hər əməliyyatda sabit xarici identifikator və ya idempotency key istifadə edilir. Eyni sifariş üçün inteqrasiya təkrar cəhd etdikdə qarşı tərəf yeni sifariş yaratmaq əvəzinə əvvəlki nəticəni qaytarmalıdır. HTTP standartı idempotent əməliyyatları təkrar cəhd üçün təhlükəsiz semantika kimi izah edir; praktik API-lərdə isə POST tipli yaradıcı əməliyyatlar üçün ayrıca idempotency açarı tətbiq olunur.
Etibarlı dublikatdan qorunma dizaynına bunlar daxildir:
- Hər mənbə sistemi üçün dəyişməyən xarici ID-ləri saxlamaq: məsələn, crm_contact_id, erp_customer_id, store_order_id.
- Müştəri uyğunlaşdırmasını yalnız adla aparmamaq; VÖEN, e-poçt, telefon və hüquqi şəxs qaydalarını ayrıca müəyyən etmək.
- İnteqrasiya cədvəlində mənbə ID-si, hədəf ID-si, əməliyyat növü, payload versiyası, status və zaman möhürü saxlamaq.
- Sifariş yaradılması, ödənişin tətbiqi və stok silinməsi üçün təkrar-təkrar işləyə bilən handler-lər qurmaq.
- Eyni SKU və anbar üzrə stok hərəkətini hadisə ID-si ilə unikal etmək.
- İnsan yoxlaması tələb edən ehtimal olunan dublikatları avtomatik birləşdirməmək.
“Müştəri tapılmadısa, yenisini yarat” qaydası yalnız uyğunlaşdırma və sahiblik siyasəti təsdiqləndikdən sonra təhlükəsizdir. Əks halda bir şirkətin eyni hüquqi şəxs üçün bir neçə kartı yarana bilər.
Uğursuz yeniləmələri görünən və idarə olunan edin
İnteqrasiyada səhvlər istisna deyil: API limiti, etibarsız sahə dəyəri, dayandırılmış ERP xidməti, dəyişdirilmiş parol və ya hədəf sistemdə biznes qaydasının pozulması baş verə bilər. Problem yalnız xətanın yaranması deyil; problemin sakitcə itməsi və komandaların onu günlər sonra stok və ya maliyyə fərqindən görməsidir.
Yaxşı inteqrasiya hər mesaj üçün qəbul edildi, emal olunur, uğurlu, təkrar gözləyir, daimi uğursuz və əl ilə araşdırma tələb edir kimi aydın statuslar saxlayır. Müvəqqəti xətalar üçün məhdud sayda artan fasiləli retry tətbiq edilir. Təkrar cəhd limiti keçilən hadisələr isə “dead-letter” və ya istisna növbəsinə düşür; burada səbəb, payload və əlaqəli biznes ID-ləri görünür. Operator sifarişi yenidən göndərməzdən əvvəl xətanı düzəldə və nəticəni audit edə bilməlidir.
Bu əməliyyat ekranı sadəcə texniki komanda üçün deyil. Maliyyə, anbar və satış rəhbərləri öz sahələrinə təsir edən uyğunsuzluqları görə bilməlidir. POLADO bu cür inteqrasiyanı ayrıca skript kimi deyil, izləmə, rol əsaslı giriş və idarəetmə iş axınları olan biznes veb platformasının hissəsi kimi layihələndirə bilər.
İnteqrasiya spesifikasiyasında mütləq olmalı bölmələr
- Sistem diaqramı və hər istiqamətdə məlumat axını;
- Hər obyekt və atribut üçün sahiblik matrisi;
- Mənbə və hədəf sahələrinin mapping sənədi;
- Status xəritəsi: məsələn, “new”, “confirmed”, “packed”, “shipped”, “delivered”, “cancelled” statuslarının dəqiq qarşılığı;
- Hadisə formatı, versiyalaşdırma və identifikator qaydaları;
- Retry, timeout, rate limit və dead-letter prosedurları;
- Dublikat aşkarlama və əl ilə birləşdirmə qaydası;
- İcazələr, tokenlərin saxlanması, audit jurnalı və məxfi məlumatların qorunması;
- İlkin məlumat köçürməsi, paralel işləmə, üzləşdirmə və geri dönüş planı;
- Qəbul testləri: qismən göndəriş, ləğv, geri qaytarma, təkrar webhook, əlaqə kəsilməsi və yanlış payload ssenariləri.
API-lər biznes məlumatlarına giriş yaratdığından, autentifikasiya, obyekt səviyyəsində icazələr, resurs limitləri və xarici API cavablarının təhlükəsiz emalı ayrıca nəzərdən keçirilməlidir. Bu sahələr OWASP API Security Top 10-da da əsas risk kateqoriyaları kimi göstərilir. Mövcud sistemlərin təhlükəsizlik və dayanıqlılıq yoxlanışı üçün texniki dəstək və konsaltinq xidməti ilə auditdən başlamaq məqsədəuyğundur.
ERP inteqrasiya tərəfdaşını seçərkən veriləcək suallar
- Komanda kodlamadan əvvəl sahiblik və mapping sənədini hazırlayacaqmı?
- ERP, CRM və çatdırılma sistemlərindəki status fərqlərini necə idarə edəcək?
- Təkrar webhook və ya timeout zamanı ikinci sifariş və ikinci stok silinməsi necə əngəllənəcək?
- Uğursuz hadisələri kim görəcək, kim düzəldəcək və necə yenidən emal edəcək?
- İlkin məlumat köçürməsindən sonra balansların, müştəri sayının və açıq sifarişlərin üzləşdirməsi necə aparılacaq?
- Yeni sistem və ya API versiyası əlavə olunanda inteqrasiya necə genişlənəcək?
POLADO satış, anbar, maliyyə və çatdırılma proseslərinin bir-birinə necə təsir etdiyini nəzərə alaraq xüsusi inteqrasiya qatları, idarəetmə panelləri və API-lər hazırlayır. Məqsəd daha bir ayrı panel yaratmaq deyil; məlumatın sahibi aydın olan, xətaları izlənən və əməliyyat komandalarının etibar edə bildiyi proses qurmaqdır. Layihənizi müzakirə etmək üçün əlaqə saxlayın və ya veb platformaların hazırlanması xidmətinə baxın.