ტექნოლოგია3 წთ საკითხავი
Webhook: როგორ მივიღოთ სისტემის შეტყობინება საიმედოდ
კლიენტმა გადაიხადა, მაგრამ შეკვეთა ისევ „გადაუხდელია“. ან ერთი შეკვეთა სისტემაში ორჯერ გაჩნდა. ორივე შემთხვევა გვაჩვენებს, რომ სისტემებს შორის შეტყობინების მიღება და ბიზნესოპერაციის სწორად დასრულება ერთი და იგივე არ არის.
Webhook არის ერთი სისტემის მიერ მეორისთვის გაგზავნილი შეტყობინება მომხდარი მოვლენის შესახებ. ის შეიძლება გვატყობინებდეს გადახდის დადასტურებას, შეკვეთის ცვლილებას ან ახალ ჩანაწერს. მიმღებმა უნდა იცოდეს, ვისგან მოვიდა შეტყობინება, უკვე დაამუშავა თუ არა და რა ქნას შეფერხებისას.
წარმატებული სცენარის მიღმაც დაგეგმეთ
შეტყობინება შეიძლება დაგვიანდეს, განმეორდეს ან მოსალოდნელი თანმიმდევრობისგან განსხვავებით მოვიდეს. Stripe-ის დოკუმენტაცია, მაგალითად, აღწერს დუბლირებულ მოვლენებსა და იმას, რომ მათი მიწოდების რიგი გარანტირებული არ არის. სხვა პროვაიდერისთვის წესები მის დოკუმენტაციაში გადაამოწმეთ.
ამიტომ მიიღეთ წინასწარი გადაწყვეტილება: რა განსაზღვრავს შეკვეთის საბოლოო მდგომარეობას, როდის არის დამატებითი API მოთხოვნა საჭირო და რომელ მოქმედებას სჭირდება ცალკე აღრიცხვა. ბრაუზერში წარმატების გვერდის გახსნა გადახდის სანდო დადასტურებად არ გამოიყენოთ; მიჰყევით გადახდის პროვაიდერის სერვერულ შემოწმებას.
გადაამოწმეთ წყარო და შეტყობინების მთლიანობა
HTTPS აუცილებელი საფუძველია, მაგრამ თავისთავად არ გვეტყვის, ვინ გამოაგზავნა მოთხოვნა. თუ პროვაიდერი ხელმოწერას იყენებს, გადაამოწმეთ იგი მისივე წესითა და შესაბამისი ბიბლიოთეკით. მაგალითად, Stripe-ის ხელმოწერის შემოწმებას მოთხოვნის უცვლელი საწყისი შიგთავსი სჭირდება.
საიდუმლო გასაღები სერვერზე შეინახეთ, საჯარო კოდსა და მისამართში კი ნუ ჩასვამთ. სატესტო და რეალური გარემოს პარამეტრები ერთმანეთისგან გამოყავით. არასწორი ხელმოწერის მქონე მოთხოვნა დამუშავებაზე არ გაუშვათ, ხოლო შემოწმებისთვის საჭირო დეტალები ჟურნალში მგრძნობიარე მონაცემების გარეშე აღრიცხეთ.
ჯერ საიმედოდ შეინახეთ, შემდეგ დაამუშავეთ
მიმღებმა ყველა გარე სისტემის პასუხს ერთდროულად არ უნდა დაელოდოს. GitHub-ის რეკომენდაციებიც შეტყობინების მიღებაზე სწრაფ პასუხსა და საჭიროებისას ფონურ რიგს აღწერს. კონკრეტული ვადა და ხელახალი გაგზავნის ქცევა პროვაიდერზეა დამოკიდებული.
პრაქტიკული მიდგომაა წყაროს გადამოწმების შემდეგ მოვლენის საიმედოდ შენახვა და მხოლოდ მერე წარმატებული მიღების დადასტურება. შემდგომ სამუშაოს ფონური პროცესი ასრულებს. თუ შენახვა ვერ მოხერხდა, წარმატებული პასუხით პრობლემა არ დამალოთ; პროვაიდერის ხელახალი ცდებისა და საკუთარი აღდგენის გეგმა წინასწარ უნდა გქონდეთ.
ერთსა და იმავე მოვლენას ორმაგი შედეგი არ მოჰყვეს
მოვლენის უნიკალური ნომერი განმეორებული მიწოდების ამოცნობაში გვეხმარება. თუმცა მხოლოდ პრინციპი „ჯერ შევამოწმებ, მერე ჩავწერ“ ერთდროული მოთხოვნებისას შეიძლება არ იყოს საკმარისი. ბაზაში შესაბამისი უნიკალურობის წესი და ბიზნესოპერაციის უსაფრთხო განმეორება დეველოპმენტის ნაწილად ჩათვალეთ.
მაგალითად, ერთი დადასტურებული გადახდის ხელახლა მიღებამ მეორე შეკვეთა ან მეორე მიწოდების დავალება არ უნდა შექმნას. ცალკე აკონტროლეთ მიღება, დამუშავების მცდელობა და დასრულებული შედეგი. წარუმატებელი ოპერაციის შემდეგ შესაძლებელი იყოს გაგრძელება ისე, რომ უკვე შესრულებული ნაბიჯი არ გამეორდეს.
ტესტები და პასუხისმგებელი ადამიანი
ჟურნალში სასარგებლოა მოვლენისა და შეკვეთის იდენტიფიკატორი, მიღების დრო, მცდელობების რაოდენობა და შეცდომის გასაგები მიზეზი. სრული გადახდის მონაცემები ან საიდუმლო გასაღებები იქ არ შეინახოთ. განმეორებად ხარვეზს შეტყობინება და პასუხისმგებელი ადამიანი სჭირდება.
- სისტემას ერთი და იგივე სატესტო მოვლენა ორჯერ მიაწოდეთ; ცალკე გამოსცადეთ ერთდროული მიღებაც.
- შეცვალეთ მოვლენების რიგი და გადაამოწმეთ საბოლოო მდგომარეობა.
- დროებით გათიშეთ მიმღები ან დაკავშირებული სატესტო სერვისი.
- გამოსცადეთ არასწორი ხელმოწერა და დაკარგული სავალდებულო მონაცემი.
- გადაამოწმეთ ხელახალი ცდა, უსაფრთხო გაგრძელება და ჩანაწერების შედარება პროვაიდერის მონაცემებთან.
ინტეგრაციის შექმნისას ამ სცენარების შეთანხმება გვაჩვენებს, რა უნდა მოხდეს მაშინაც, როცა რომელიმე სისტემა აგვიანებს. მუშაობის შემდეგ კი ტექნიკური მხარდაჭერა ამ მოვლენების კონტროლსა და დროულ რეაგირებასაც მოიცავდეს.
