ინტეგრაციისა და API-ს გზამკვლევი ბიზნესისთვის
ბიზნესში ერთი და იგივე მონაცემი, როგორც წესი, რამდენიმე ადგილას დგას: შეკვეთები ელკომერციის პანელში, ინვოისები ბუღალტრულ პროგრამაში, კლიენტების ინფორმაცია ცხრილში. როცა ეს სისტემები ერთმანეთს არ ესაუბრება, მათ შორის გადატანას ადამიანი აკეთებს და შეცდომაც იქ იწყება.
რა არის API, რას მატებს ჩემს ბიზნესს?
API ორი პროგრამის მიერ ერთმანეთისთვის მონაცემის მოთხოვნისა და გაგზავნისთვის განსაზღვრული ინტერფეისია. პრაქტიკული შესატყვისი ასეთია: თქვენს საიტზე შეკვეთის შექმნისას ბუღალტრულ პროგრამაში ინვოისის თავისთავად ჩავარდნა, საკურიერო კომპანიისგან თვალყურის დევნების ნომრის ავტომატურად მოსვლა ან მარაგის ინფორმაციის ორ სისტემაში ერთდროულად განახლება.
მოგება ორი ადგილიდან მოდის. პირველი დროა: ხელით მონაცემების შეყვანა ქრება. მეორე და უფრო მნიშვნელოვანი — სიზუსტე: როცა ერთი და იგივე ინფორმაცია ორ ადგილას ხელით შეიყვანება, ადრე თუ გვიან განსხვავდება და იწყება კამათი, რომელია სწორი.
რომელი ინტეგრაცია მოაქვს რეალურად სარგებელი
ყოველი კავშირის აწყობა არ ღირს. ამ კრიტერიუმით გადაწყვიტეთ: ოპერაციის სიხშირე × შეცდომის ღირებულება.
თვეში სამჯერ შესრულებული და შეცდომის შემთხვევაშიც ადვილად გასასწორებელი გადატანისთვის ინტეგრაცია ძვირია. სამაგიეროდ, დღეში ორმოცდაათჯერ განმეორებადი ან შეცდომისას კლიენტზე ამსახველი გადატანა (შეკვეთა, მარაგი, ინვოისი) ინტეგრაციას რამდენიმე თვეში ამორტიზებს.
ყველაზე ხშირად მომგებიანი ოთხი კავშირი ასეთია: ელკომერცია და ბუღალტერია, საიტის ფორმა და CRM, მარაგი და მარკეტპლეისი, კურიერის თვალყურის დევნება და კლიენტის შეტყობინება.
ინტეგრაციის ტიპები
- მზა კავშირი. ორ პოპულარულ სისტემას შორის მწარმოებლის მიერ შეთავაზებული მოდული. ყველაზე იაფი და სწრაფი გზა; მოქნილობა არ აქვს.
- შუამავალი სერვისი. სისტემების ერთმანეთთან დამაკავშირებელი მესამე მხარის პლატფორმები. კოდის წერის გარეშე ყენდება, ყოველთვიური საფასურია, რთულ წესებში არასაკმარისია.
- ინდივიდუალური დეველოპმენტი. ორი სისტემის API-ების გამოყენებით დაწერილი კავშირი. ყველაზე მოქნილი; თუ თქვენი სამუშაო ნაკადი თავისებურია, ერთადერთი რეალისტური ვარიანტი.
თანმიმდევრობაც ეს უნდა იყოს: ჯერ ნახეთ, არის თუ არა მზა კავშირი, თუ არა — შუამავალი სერვისი განიხილეთ, თუ ისიც არ კმარა — ინდივიდუალური დეველოპმენტი გააკეთეთ.
რა განსაზღვრავს ღირებულებას
ინტეგრაციის შეთავაზებებში სხვაობა, როგორც წესი, ამ ოთხი პუნქტიდან მოდის:
- მეორე სისტემას აქვს API და დოკუმენტირებულია? არადოკუმენტირებულ ან დახურულ სისტემასთან მუშაობა ვადას აორმაგებს.
- გადატანა ცალმხრივია თუ ორმხრივი? ორმხრივ გადატანაში კონფლიქტის წესებიც უნდა განისაზღვროს.
- რამდენი მონაცემი, რა სიხშირით? მყისიერი გადატანა და დღეში ერთი მასობრივი გადატანა სხვადასხვა სტრუქტურას მოითხოვს.
- შეცდომის შემთხვევაში რა მოხდება? მთავარი საქმე აქ არის: კავშირის გაწყვეტისას მონაცემი არ უნდა დაიკარგოს, ხელახლა უნდა იცადოს და ვიღაცამ უნდა გაიგოს.
მეოთხე პუნქტი შეთავაზებებში ყველაზე ხშირად გამოტოვებული და შემდგომში ყველაზე მეტი პრობლემის მომტანი ელემენტია.
რაზე უნდა გადაწყდეს თავიდანვე
- რომელი სისტემაა მთავარი წყარო? თუ ერთი და იგივე ინფორმაცია ორ ადგილასაა, რომელი ჩაითვლება სწორად? ამ კითხვის უპასუხოდ აწყობილი ინტეგრაცია პირველივე კონფლიქტზე ჩერდება.
- რომელი ველები გადაიტანება? ყველა ველის გადატანა საჭირო არ არის; ზედმეტი მონაცემის გადატანა რისკსაც ზრდის და მოვლის ტვირთსაც.
- აუთენტიფიკაცია როგორ იქნება? გასაღებები სად შეინახება, ვის ექნება წვდომა, ვადის გასვლისას ვინ განაახლებს.
- სატესტო გარემო არსებობს? ლაივ მონაცემით ტესტირების იძულება ინტეგრაციის პროექტებში ყველაზე დიდი რისკია.
მონიტორინგის გარეშე ინტეგრაცია ნახევარია
აწყობილი კავშირი ჩუმად მუშაობს და ჩუმად ჩერდება. ბიზნესების უმეტესობა ინტეგრაციის გაფუჭებას დღეების შემდეგ, კითხვით „ინვოისები რატომ არ მოდის“ ამჩნევს.
ამიტომ ყოველ ინტეგრაციას სამი რამ უნდა ჰქონდეს: წარუმატებელი ოპერაციების ჩანაწერი, ხელახლა ცდის მექანიზმი და გარკვეული ზღვრის გადამეტებისას შეტყობინება. ესენი დეველოპმენტის ღირებულებას გარკვეულწილად ზრდის, მაგრამ სისტემის მართლა სანდოობას სწორედ ეს ნაწილი უზრუნველყოფს.
მოკლე შენიშვნა მონაცემთა ფორმატებზე
სისტემებს შორის მონაცემთა გაცვლაში ყველაზე გავრცელებული ფორმატი JSON-ია. ინტეგრაციის პრობლემის შესწავლისას ხშირად ხელში მოსული ნედლი მონაცემის წასაკითხ ფორმაში მოყვანა და ველების სწორად მოსვლის შემოწმებაა საჭირო.
ასევე, სერვისში გაგზავნილი საიდენტიფიკაციო ინფორმაციის (token) შინაარსის შემოწმება ან ტექსტის დაკოდირებული ფორმის გაშიფვრა ხშირად შემხვედრი საქმეებია. მათთვის რთული ინსტალაცია საჭირო არ არის.
როდის არ უნდა გაკეთდეს ინტეგრაცია
თუ პროცესი ჯერ არ ჩამოყალიბებულა, ინტეგრაცია ნაადრევია. ცვალებადი სამუშაო ნაკადის კოდში ჩაწერა ყოველ ცვლილებაზე დეველოპმენტის ხარჯს ქმნის.
ასევე, სისტემის, რომლის შეცვლასაც უახლოეს მომავალში აპირებთ, დაკავშირებაც ფლანგვაა. ჯერ სისტემაზე გადაწყვიტეთ, მერე დააკავშირეთ.
ინტეგრაციის პროექტის ეტაპები
ჯანსაღად მიმდინარე ინტეგრაციის პროექტი ამ თანმიმდევრობას მიჰყვება და ყოველ ნაბიჯს შედეგი აქვს:
- პროცესის რუკა. რომელი მონაცემი საიდან სად, რომელი ტრიგერით წავა. ამ ნაბიჯის გამოტოვებისას დეველოპმენტისას მუდმივად ჩნდება კითხვები.
- ველების შესაბამისობა. ორი სისტემის ველების ერთმანეთთან შესატყვისობა. „კლიენტის სახელი“ ერთ სისტემაში ერთი ველია, მეორეში — სახელი და გვარი.
- სატესტო გარემოში დაყენება. ლაივ მონაცემთან შეხების გარეშე.
- კონტროლირებადი გადასვლა. ჯერ მცირე მონაცემთა ნაკრებით, ხელით გადამოწმებით.
- მონიტორინგი და გადაბარება. შეცდომის შეტყობინება ვისთან წავა, პრობლემისას ვინ ჩაერევა.
მეორე პუნქტი შეთავაზებებში ყველაზე მეტად შეუფასებელი ელემენტია; ველების შესაბამისობის დაზუსტებამდე მიცემული ვადების შეფასებები თითქმის ყოველთვის ცდება.
სიჩქარე და ლიმიტები
ყოველ API-ს აქვს ლიმიტი, გარკვეულ დროში რამდენ მოთხოვნას მიიღებს. ამ ლიმიტის გადამეტებისას მოთხოვნები უარყოფილია და ინტეგრაცია ჩუმად იწყებს მონაცემთა კარგვას.
ამიტომ გადატანის დაპროექტებისას ორი რამ უნდა განიხილოს: მყისიერი თუ მასობრივი, და ლიმიტთან შეჯახებისას რა მოხდება. მასობრივი გადატანა (მაგალითად, საათში ერთხელ) საქმეების უმეტესობისთვის საკმარისია და უფრო იაფიცაა და უფრო გამძლეც. მყისიერი გადატანა მხოლოდ იქ არის საჭირო, სადაც დაგვიანება მართლა პრობლემაა — მარაგი და ფასი.
უსაფრთხოების მხარე
ინტეგრაცია ორ სისტემას შორის მუდმივ კარს ხსნის. იმ კარის გასაღები — API გასაღებები — კოდში არ უნდა ჩაიშენოს, ვერსიების კონტროლში არ უნდა მოხვდეს და შეძლებისდაგვარად ყველაზე ვიწრო უფლებით უნდა შეიქმნას.
მხოლოდ შეკვეთების წამკითხველი კავშირისთვის კლიენტის წაშლის უფლების მიცემა გავრცელებული და ზედმეტი რისკია. გასაღებები ვის მიერ, როდის შეიქმნა და ვადის გასვლისას ვინ განაახლებს — თავიდანვე უნდა განისაზღვროს.
რა უნდა ჩაიბაროთ ინტეგრაციის დასრულებისას
პროექტის დახურვისას ხელში უნდა გქონდეთ: სქემა, რომელი მონაცემი სად მიედინება, ინფორმაცია, გამოყენებული გასაღებები სად ინახება, შეცდომისას შეტყობინება ვისთან მიდის და როგორ ჩერდება და ხელახლა იწყება სისტემა.
თუ ეს დოკუმენტები არ არის, ინტეგრაცია შავ ყუთად იქცევა. როცა მის ამწყობ გუნდს დაშორდებით, მომუშავე, მაგრამ არავისთვის გასაგებ კავშირთან რჩებით; პირველივე გაუმართაობისას ერთადერთი ვარიანტი თავიდან დაწერინება ხდება.
განსხვავება webhook-სა და გამოკითხვას შორის
ორი სისტემა ერთმანეთს ორნაირად ატყობინებს. გამოკითხვის მეთოდში თქვენი სისტემა გარკვეული ინტერვალით კითხულობს „არის რამე ახალი?“; დაყენება მარტივია, მაგრამ დაგვიანებას ქმნის და ზედმეტ მოთხოვნებს აწარმოებს.
Webhook-ის მეთოდში კი მოვლენის მოხდენისთანავე მეორე სისტემა თავად გატყობინებთ. უფრო სწრაფი და ეფექტიანია; სანაცვლოდ თქვენს მხარეს მუდმივად მისაწვდომი მისამართი უნდა იყოს და შემოსული შეტყობინების მართლა იმ სისტემიდან მოსვლა უნდა გადამოწმდეს. შეძლებისდაგვარად webhook უპირატესია.
JSON გამოსავლის ფორმატირებისთვის, დაკოდირებული მონაცემის გასაშიფრად ან საიდენტიფიკაციო ინფორმაციის შინაარსის სანახავად დეველოპერის ინსტრუმენტების გვერდზე არსებული ინსტრუმენტები გამოიყენეთ. კორპორატიული ინტეგრაციისა და ავტომატიზაციის სამუშაოები ჩვენი სერვისების ფარგლებშია.