ما هو المطلوب لبناء نظام بيئي للخدمات غير المصرفية ، وبالفعل أي نظام بيئي مماثل؟ نظام رئيسي لتخزين ومعالجة البيانات ، بالإضافة إلى API. في هذا المنشور ، سنقوم بتحليل نسختين من واجهة برمجة التطبيقات التي أنشأناها - الأول والأكثر نجاحًا - وسنتحدث عن الاختلافات المهمة بينهما.
لإنشاء نظام بيئي للخدمات غير المصرفية ، تم اختيار منتج رئيسي لقسم بنك Sberbank Digital Corporate Bank - وهو بنك إنترنت لعملاء الشركات في Sberbank Business Online. وبناءً على ذلك ، تم إنشاء واجهة برمجة تطبيقات FINTECH للنظام البيئي للخدمات غير المصرفية على أساسها.
تم إطلاق الإصدار الأول من واجهة برمجة تطبيقات fintech في عام 2016. تم إنشاؤه مع التركيز على واجهات برمجة التطبيقات الأخرى لبنكنا ، وفقًا للوصفات الكلاسيكية لواجهات برمجة التطبيقات للمؤسسات المالية الكبيرة. فيما يلي المكونات الرئيسية:
- بروتوكول SOAP لنقل البيانات
- تنسيق XML
- التوقيع الإلكتروني لجميع الطلبات
- عملية غير متزامنة
- الأجهزة-VPN المطلوبة لقناة آمنة
- نظام المصادقة والتخويل الملكية
- التنسيقات الراسخة تاريخيا لنقل المعلومات المالية (على سبيل المثال ، التنسيق المصرفي المباشر 1C)
لقد اتخذنا مثل هذا القرار وبدأنا عمليات دمج تجريبية مع العديد من الخدمات المصرفية غير الكلاسيكية: متجر Evotor عبر الإنترنت ونظام Seeneco Business Analytics للإدارة المالية والمحاسبة المستندة إلى السحابة MyOdelo وغيرها.
كانت نتائج التكامل بعيدة عن المطلوب. من واجهة برمجة التطبيقات للخدمات غير المالية الحديثة ، لم يتوقع الشركاء على الإطلاق ما هو المعتاد في تطوير المنتجات المصرفية الكلاسيكية. أردنا الحصول على شيء مشابه لواجهة برمجة التطبيقات لعمالقة الإنترنت الحديثة: Facebook و Google و Yandex.
وفي النهاية ، صادفوا واجهة برمجة تطبيقات مصرفية كلاسيكية - ثقيلة وغامضة وتتطلب مهارات عالية ومحددة ، وفهم تعقيدات عمليات العمل ، وتنفيذ متطلبات الأمان المفرطة ... بشكل عام ، الكثير من الأشياء التي تؤدي إلى انتهاك جميع المواعيد النهائية المحتملة للتكامل.
قمنا بتحليل هذه التجربة وقررنا عمل نسخة جديدة من واجهة برمجة تطبيقات fintech من الصفر. للحصول على الحد الأقصى من الربح مع الخدمات غير المالية من جهات خارجية ، يتم توضيح أهم المتطلبات مسبقًا:
- لا توجد تنسيقات عالمية وثقيلة تأخذ في الاعتبار أدنى الفروق الدقيقة. دعونا نكون أسهل!
- يجب أن تتناسب واجهة برمجة التطبيقات مع أكبر مجموعة ممكنة من الشركاء المحتملين الذين يقدمون منتجات غير مالية لعملاء Sberbank. حتى إدخال الثلاجات الذكية - ما لا يمزح الجحيم.
- يجب تصميم واجهة برمجة التطبيقات باستخدام الممارسات والأساليب المستخدمة لإنشاء واجهات مرئية. للقيام بذلك ، تحتاج إلى تحديد وتحليل مخططات UX لاستخدام API. من المؤكد أن اتباع الشرائع الكلاسيكية لا يستحق ذلك.
- نحتاج إلى التخلص من الأوصاف متعددة الأحجام حتى يتمكن المطورون من تحقيق نتائج سريعة. باستخدام وضع الحماية للتجارب الاختبارية ، تحتاج إلى الحصول على النتائج الإيجابية الأولى في غضون ساعة.
- نحن نرفض الحلول الخاصة المرتبطة بمنصة معينة قدر الإمكان. يجب أن يكون كل شيء عبر منصة وليس الحد من الشريك في البنية التحتية المستخدمة وبيئة التطوير.
- لا ينبغي أن ينزعج الشركاء مما لا يفعلونه - هياكل البيانات المعقدة ، وآليات مكونات النظام الأساسي المصرفي ، وميزات أنظمتنا القديمة. نختبئ ولا ندفن رؤوسهم.
مع هذه القائمة ، انتقلنا إلى التنفيذ والحلول المختارة للإصدار الثاني من واجهة برمجة تطبيقات fintech:
- المصادقة المستندة إلى OAUTH 2.0
- بنية REST عبر HTTP بدون تعقيد إضافي
- عملية متزامنة بالكامل
- تنسيق JSON
- الاستخدام الاختياري للتوقيع الإلكتروني - عند الضرورة
- اختبر وضع الحماية باستخدام SWAGGER المنتشر. باستخدام بيئة تصحيح الأخطاء هذه ، يمكن لمطور الشريك محاكاة سير عمل الأعمال والحصول على النتائج دون كتابة تعليمات برمجية
- تطبيق نهج الخطوات السهلة الذي تستخدمه شركات الإنترنت الناشئة لإنشاء وثائق API
- الممارسات الرشيقة لتطوير API - نتائج سريعة وجمع الملاحظات
ما تغير في الواقع
لتقييم الفرق بين نسختين من واجهة برمجة التطبيقات ، نقوم بمقارنة تنفيذ مكوناته الرئيسية الثلاثة: التفويض ، وتنفيذ أمر دفع الروبل والتوقيع الإلكتروني.
في الإصدار الأول من واجهة برمجة التطبيقات ، للحصول على تفويض ، طلب الشريك اسم مستخدم وكلمة مرور وشهادة و AccessToken تم الحصول عليهما نتيجة مصادقة OAUTH للعميل الذي تقدم بطلب:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/"> <soapenv:Header/> <soapenv:Body> <upg:preLogin> <upg:userLogin>U1</upg:userLogin> <upg:changePassword>!d63NvJ+Sa</upg:changePassword> </upg:preLogin> </soapenv:Body> </soapenv:Envelope>
في API 2.0 ، أصبح التفويض أكثر إحكاما. للوصول إلى الخدمات ، ما عليك سوى استلام AccessToken أثناء مصادقة OAUTH للعميل:
{ "access_token": "fdba5482-460c-4535-b829-9fd836fd01f0-1", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "7f545a14-ab7b-45ff-823a-0421e9f3b42e-1", }
في API 1.0 ، كان العمل مع أمر الدفع الروبل يستند أيضًا إلى SOAP:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:upg="http://upg.sbns.zzzzz.com/"> <soapenv:Header/> <soapenv:Body> <upg:sendRequestsSRP> <upg:requests><![CDATA[ <Request xmlns='http://zzzzz.com/upg/request' orgId='84b70f22-703f-bf04-db60-bd110572f40d' requestId='a81ddc6d-fb92-416d-83f9-6785a59a4b17' version='1.0' sender='PARTNER' clientOrgIdHash='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5' clientAccessToken='ee0fb56b01a9d9b9648a2c60549b77702eb2a6de8f2189c4349447e43b250da5-1'> <PayDocRuInvoice docExtId='a81decfd-fb92-416d-83f9-6785a59abb65' orderNum='62' deadLine='2017-04-10T17:16:03'> <PersonalAcc>40802810000000000000</PersonalAcc> <AccDoc docDate='2017-02-15' docSum='777' transKind='01' paytKind='01' priority='1'> <Purpose>!!!!! 18%</Purpose> </AccDoc> </PayDocRuInvoice> </Request> ]]></upg:requests> <upg:sessionId>5a869c00-e979-4280-b11a-6dbbb8a90214</upg:sessionId> </upg:sendRequestsSRP> </soapenv:Body> </soapenv:Envelope>
في API 2.0 ، بطريقة مشابهة ، أصبح كل شيء أبسط وأكثر قابلية للفهم:
{ "amount": 12.01, "date": "2018-06-22", "deliveryKind": "", "expirationDate": "2018-06-23", "externalId": "1516ec0c-761c-11e8-adc0-fa7ae01bbebc", "operationCode": "01", "orderNumber": "1237", "payeeAccount": "40706810000000000000", "paymentNumber": "1", "priority": "5", "purpose": " №1237. .", "urgencyCode": "NORMAL", "vat": { "amount": 100.01, "rate": "7", "type": "NO_VAT" }
كما قمنا بتسهيل التوقيع الإلكتروني. هذا ما كان عليه في API 1.0.
لذا بدا الطلب
هنا قائمة السمات
والآن التوقيع النهائيفي API 2.0 ، كان كل شيء أسهل من خلال JSON:
تطلب نفسها
التوقيع نتيجة لذلكالملخص
أظهرت عمليات الإطلاق التجريبية لـ FINTECH API 2.0 أن الأمور سارت على ما يرام. تم تقليل وقت التكامل مع المنتجات الشريكة - من بداية العمل حتى لحظة الإصدار في التشغيل التجاري - بأكثر من 3 مرات. تم تقليل عدد الأسئلة لخدمة مرافقتنا بترتيب من حيث الحجم ، والأهم من ذلك ، انخفض تعقيد هذه القضايا. أخيرًا ، تم تقليل عدد الشكاوى المتعلقة بتعقيد واجهة برمجة التطبيقات وعدم إمكانية التنبؤ بها بمقدار أمرين. بشكل عام ، فعلنا ذلك. إذا كانت لديك أسئلة ، فمرحبًا بك في التعليقات ، وسنخبرك بكل سرور بالتفاصيل.
تم إعداد المواد من قبل أندريه خوخلوف ، مدير المشروع في Digital Digital Bank Sberbank