// axborot tizimlarini API orqali integratsiya qilish

Axborot tizimlarini integratsiya qilish texnik topshirig'i: nimalar odatda yozilmay qoladi

Bunday xaridda odatda ikki-uch tizimni bir-biriga ulash so'raladi: hisob-kitob (uchot) tizimi, CRM, to'lov shlyuzi yoki idoraviy xizmat. Buyurtmachi ko'pincha davlat organi yoki yirik kompaniya bo'ladi: tizimlarning o'zi allaqachon ishlab turadi, ularni endi bir butun jarayonga bog'lash kerak.

Integratsiya loyihasining o'ziga xosligi shundaki, ish faqat pudratchi qo'lida emas. Natija ikkinchi tomonning API'siga, uning test muhitiga va ma'lumotlar egasining qarorlariga bog'liq. Shuning uchun loyiha taqdiri ko'pincha kodlash boshlanishidan oldin, texnik topshiriq yozilayotgan paytda hal bo'ladi.

Quyida shunday topshiriqlarda tez-tez uchraydigan to'rtta-beshta bo'sh joy ko'rib chiqiladi: ular topshirishda qanday munozaraga aylanishi va ularni topshiriqda qanday yopish mumkinligi bayon etiladi. Bu aniq xarid emas, tipik hujjatning umumiy tahlili.

Texnik topshiriqda odatda nima e’tibordan chetda qoladi

Tizimlar nomi bilan sanalgan, lekin ularning API tavsifi yo'q

Oqibati. Pudratchi taklifni taxminga tayanib beradi, ish boshlangach esa API kutilganidan boshqacha chiqadi. Hajm va muddat qayta ko'riladi, topshirishda esa «nima integratsiya qilinishi kerak edi» degan bahs boshlanadi.

Qanday to‘g‘ri yozish kerak. Topshiriqda har bir tizim uchun alohida bo'lim bo'lsin: protokol va format, hujjat (spetsifikatsiya) versiyasi, autentifikatsiya usuli, almashiladigan ma'lumotlar ro'yxati. Agar tavsif hali mavjud bo'lmasa, buni ochiq yozing va uni tayyorlash vazifasini alohida bosqich qilib belgilang.

API'ni kim va qachon taqdim etishi aytilmagan

Oqibati. Ikkinchi tomon (boshqa idora yoki boshqa pudratchi) hujjat va ruxsatlarni kechiktirsa, pudratchi kutib qoladi, muddat esa shartnoma bo'yicha o'tib ketadi. Kechikish sababi kimdaligini isbotlash qiyin.

Qanday to‘g‘ri yozish kerak. «Buyurtmachi majburiyatlari» bo'limida: API hujjati va kirish ruxsatlarini kim, qaysi muddatgacha va qaysi shaklda beradi. Shu majburiyat bajarilmaganda pudratchi muddati qanday o'zgarishi ham shu yerda yozilsin.

Almashinuv uzilganda nima qilish kerakligi yozilmagan

Oqibati. Tarmoq uzilishi yoki ikkinchi tizim vaqtincha ishlamay qolsa, ma'lumot yo'qoladi yoki ikki marta yoziladi. Bu to'lov va hisob ma'lumotlarida ayniqsa og'ir oqibatga olib keladi, ishlab chiqarishda esa har bir holat alohida bahsga aylanadi.

Qanday to‘g‘ri yozish kerak. Xatolik senariylari bo'limi: qayta urinish (necha marta va qanday oraliqda), navbat yuritilishi, takroriy so'rovdan himoya, javobgar xodimga ogohlantirish va qo'lda qayta ishlash tartibi. Har bir senariy uchun kutilgan natija qabul sinovida tekshiriladigan shaklda yozilsin.

Ikkinchi tomonda test muhiti yo'q yoki u haqida jim

Oqibati. Integratsiyani sinash faqat jonli tizimda mumkin bo'lib qoladi: bu xavfli, ko'pincha ruxsat etilmaydi. Natijada sinov chala o'tadi, kamchiliklar ishga tushirilgandan keyin chiqadi.

Qanday to‘g‘ri yozish kerak. Topshiriqda har bir tizim uchun test (sandbox) muhiti talab qilinsin, uni kim taqdim etishi va test ma'lumotlari qanday bo'lishi yozilsin. Agar test muhiti umuman mumkin bo'lmasa, o'rniga imitator (mock) yaratish alohida ish sifatida hajmga kiritilsin.

Tizimlar tutashgan joyda ma'lumot uchun javobgarlik taqsimlanmagan

Oqibati. Ma'lumot noto'g'ri yoki to'liq kelmasa, har bir tomon aybni boshqasiga yuklaydi: tizim egasi, integrator va ma'lumot manbai. Ish to'xtab qoladi, chunki tuzatishga hech kim vakolatli emas.

Qanday to‘g‘ri yozish kerak. Ma'lumotlar egasi jadvali: har bir ma'lumot turi uchun manba tizim, yagona haqiqat manbai, kim tuzatadi va kim tasdiqlaydi. Maydonlarning moslashtirilishi (mapping) va formatlar ham hujjatga ilova qilinsin.

Almashinuv jurnali (log) talab qilinmagan

Oqibati. Bahsli holatda «yuborilgan, lekin qabul qilinmagan» yoki aksincha ekanligini isbotlab bo'lmaydi. Har bir muammo taxmin va yozishmaga aylanadi, topshirishda esa dalil yo'q.

Qanday to‘g‘ri yozish kerak. Jurnalga talab: har bir so'rov va javob uchun vaqt, yo'nalish, identifikator, holat va xatolik kodi yozilsin; saqlash muddati va jurnalni ko'rish huquqi (kim ko'ra oladi) belgilansin. Maxfiy ma'lumotlarni jurnalda niqoblash qoidasi ham qo'shilsin.

Yaxshi texnik topshiriq nima beradi

Buyurtmachi uchun: aniq API va majburiyatlar tufayli taklifdagi narx va muddat taqqoslanadigan bo'ladi, loyiha kutilmagan qo'shimcha ishlarsiz boradi.

Qabul sinovi taxminga emas, topshiriqdagi tekshiriladigan shartlarga tayanadi: xatolik senariylari va jurnal bahsni qisqartiradi.

Pudratchi uchun: nima uning zimmasida, nima boshqa tomonda ekani oldindan ma'lum, shuning uchun baho ham, muddat ham asosli beriladi.

Ikkala tomon uchun: tizimlar tutashgan joyda javobgarlik oldindan taqsimlangan, shu sababli bahsli vaziyatda jurnalga murojaat qilish kifoya.

Narxi va muddati

Texnik topshiriq — $400 dan, 1–4 hafta: narx tizim murakkabligi, arxitektura, stek va integratsiyalarga bog‘liq. Subpudratda ishlab chiqish — shartnoma hajmiga qarab, baho ariza topshirishdan oldin.

Tender uchun texnik topshiriq yoki subpudrat — batafsil →

Buyurtmachilar va xaridlarni nomlamaymiz: kimningdir tenderini emas, odatiy texnik topshiriqni tahlil qilamiz.

Xaridga tayyorlanyapsizmi yoki tenderni allaqachon yutdingizmi?

Tenderni muhokama qilish