ԸՆԴՀԱՆՈՒՐ ՊԱՏԿԵՐ
Համատեքստ
Business Application-ը պետք է կապեր օգտատիրոջ account-ի և վճարումների վիճակը payment terminal-ների ու արտաքին access-control / intercom համակարգի հետ։
ԽՆԴԻՐ
Ինչ պետք էր լուծել
Օգտատիրոջ վճարման և account-ի վիճակը պետք էր ճիշտ արտացոլվեր նաև ֆիզիկական մուտքի համակարգում։ Վճարման, օրական հաշվարկների կամ account-ի կարգավիճակի փոփոխությունից հետո համակարգը պետք է ճիշտ որոշեր՝ ակտիվացնել, սահմանափակել, թե վերականգնել մուտքը։
ՍԱՀՄԱՆԱՓԱԿՈՒՄՆԵՐ
Ինչ պետք էր հաշվի առնել
- Հանրային նկարագրության մեջ չեն բացահայտվում vendor-ի protocol-ները, private endpoint-ները, device identifier-ները, credentials-ը, օգտատերերի տվյալները կամ payment configuration-ը։
- Ֆիզիկական մուտքի կարգավիճակը պետք է որոշվեր Business Application-ի հստակ կանոններով, ոչ թե առանձին device-ների ներսում պահվող տրամաբանությամբ։
ԻՄ ՊԱՏԱՍԽԱՆԱՏՎՈՒԹՅՈՒՆԸ
Systems Integration & Implementation
- Business Application-ը կապել եմ արտաքին access-control համակարգի հետ՝ իրականացնելով օգտատերերի provisioning-ը, մուտքի ակտիվացումը, սահմանափակումը և հետագա վերականգնումը։
- Իրականացրել եմ օրական հաշվարկներն ու կանոնները, որոնց հիման վրա վճարման և account-ի վիճակը որոշում է օգտատիրոջ access status-ը։
- Իրականացրել եմ նաև վճարումից հետո օգտատիրոջ մուտքի ակտիվացման կամ վերականգնման անհրաժեշտ հոսքը payment terminal infrastructure-ի հետ։
ՃԱՐՏԱՐԱՊԵՏՈՒԹՅՈՒՆ
Համակարգերի կապը
Payment Terminal Infrastructure
Business Application
Օրական հաշվարկներUser / Account StateAccess Rules
Integration Layer
Access-Control System
Provision UserActivate AccessBlock / Restore Access
ՏԵԽՆԻԿԱԿԱՆ ԲԱՐԴՈՒԹՅՈՒՆՆԵՐ
Որտեղ էր բարդությունը
- Վճարման և account-ի վիճակը պետք էր միանշանակ վերածել համապատասխան access action-ի՝ առանց business logic-ը տեղափոխելու արտաքին սարքերի կամ vendor համակարգի մեջ։
- Provisioning-ի, activation-ի, blocking-ի և reactivation-ի քայլերը պետք էր պահել որպես մեկ ամբողջական user lifecycle, որպեսզի տարբեր համակարգերում օգտատիրոջ վիճակը չտարբերվեր։
- Vendor-ին հատուկ integration logic-ը պետք էր առանձնացնել Business Application-ի վճարային հաշվարկներից և access rule-երից։
ՄՈՏԵՑՈՒՄ
Ինչպես կառուցվեց լուծումը
- Վճարումների և account-ի վիճակը պահվում և հաշվարկվում է Business Application-ում։
- Business rules-ը որոշում են, թե ինչ access state պետք է ունենա օգտատերը, իսկ integration layer-ը այդ որոշումը փոխանցում է արտաքին access-control համակարգին։
- Provisioning-ը, activation-ը, blocking-ը և reactivation-ը իրականացվում են որպես հստակ սահմանված workflow-ներ, ոչ թե business logic-ի տարբեր հատվածներում ցրված device command-ներ։
ԱՐԴՅՈՒՆՔ
Ինչ ստացվեց
- Իրականացվել է ինտեգրում, որի միջոցով Business Application-ը կարող է վճարման և account-ի կանոնների հիման վրա կառավարել օգտատիրոջ ֆիզիկական մուտքը՝ provisioning-ից ու activation-ից մինչև սահմանափակում և վերականգնում։
ՏԵԽՆԻԿԱԿԱՆ ՀԱՄԱՏԵՔՍՏ
Տեխնոլոգիաներ և համակարգեր
Systems integrationPayment terminal integrationAccess-control integration
Vendor-ի անունը, protocol-ները, credentials-ը, private endpoint-ները, device identifier-ները, օգտատերերի տվյալներն ու payment configuration-ը միտումնավոր չեն հրապարակվում։