Adobe integration and one-stop subscription platform development

ActivePlatform helps companies act as cloud service brokers, enabling telecommunications companies and mobile operators, service providers, resellers, entrepreneurs, and government organizations to cost-effectively provide IT as a service. The platform allows them to build an end-to-end ecosystem that helps customers quickly find, acquire, and manage cloud services through their own specialized system, according to their immediate needs.

Essentially, ActivePlatform allows users to buy subscriptions to cloud and other services from different companies, all in one place. If your company needs subscriptions, for example, to Google Cloud, Microsoft Office, and Adobe, then instead of going to each website to order and register these products, you can simply go to the ActivePlatform and order all of these services using one account, create invoices, and pay in one place using one currency.

Evrone developers are integrated into the ActivePlatform team and work on the aspects that relate to resellers, administrators, managers, and customers (buyers at the company level). Namely, we have worked on integration with Adobe, payment systems integration, implementation of billing systems for various vendors, integration with external tax calculation engines, etc.

How it all started

ActivePlatform is a large, complex project. In September 2021, they turned to Evrone to recruit people for outstaffing and, as a test solution, outsourced Adobe integration with their platform to Evrone. The platform already had a module that was designed to work with microservices, and we implemented the service for working with Adobe. They liked the way we operated, so they recruited our team members for outstaffing, and now we work right alongside their in-house team.

There are three Ruby teams working on the platform, which include developers from Evrone and a JS team. Each team has both testers and developers.

Integration with Adobe

While working on the integration with Adobe, we implemented three things:

• Ordering a subscription
• Changing a subscription
• Renewing a subscription

Integration with Adobe is a very voluminous and specific task, because even just ordering a subscription is not a simple request. First we get the data, then we create a customer on the Adobe side. Then we check their status and wait for them to be created — which can take several minutes. Next, we compare what we want to receive as a subscription with what Adobe has to offer. Resource codes from some subscription elements may differ by a couple of characters, so you need to match them, create an order, wait for it to go through, then turn off the update on the Adobe side. Finally, we again get the customer data on the platform side, and only after that do we take all the data from there and return it to the platform.

This entire described process is just creating a subscription — that's it. So, a huge amount of work was done in order to implement one thing: a subscription order. Subscription renewal implementation also required a significant amount of work, but there are fewer steps.

Implementing asynchronous work with Adobe

After we implemented the integration with Adobe, we made the work with Adobe asynchronous. In the platform, initially, work with microservices for vendors has always been exclusively synchronous — question-answer, question-answer. And since Adobe sometimes responds to some requests for several hours, it was decided to use microservices asynchronous message-based communication. So we have implemented a mechanism that allows it to work asynchronously, that is, send a request, transfer information, verify its validity and relevance of the data for identification, then receive the answers asynchronously through the RabbitMQ message broker.

Almost every action — ordering a subscription, renewing a subscription, updating a subscription — occurs through a number of scenarios. For example, checks, formation of write-offs, formation of payments, checks for sanctions if necessary, then sending. These are all huge scenarios. In order for these scripts not to be interrupted, it was necessary to implement asynchronous work. It was difficult, but it was implemented.

Another difficulty was that, during the work, Adobe changed the logic inside itself and did not report it in any way. We had to rebuild directly in the process of work, but in the end, everything turned out great.

Integrating Adobe with a custom application was difficult, because we weren't familiar with the documentation for the platform yet. Each microservice must conform to existing documentation. We do not create a microservice and set which methods should be used. Rather, the existing documentation says what will come to it and what it should return. Adobe itself is also highly specific in places, because, for example, you need to make eight different requests just to order a subscription — not counting the receipt of a token. So nine requests, if everything happens instantly, and some requests can be repeated every 10 seconds for hours.

Integration with payment systems

In addition to integration with Adobe, we also worked on custom payment gateway integration with different payment systems — Kazakh EPAY, for example. We also integrated with the Softline payments system, which is now deployed in Argentina and Colombia. We were responsible for the entire process — everything from idea to implementation — as well as maintenance, payment system testing, and deployment.

In addition, we also took care of current tasks, improvements to current iterations, and implementation of new billing types.

New billing types

The implementation of billing type requires a huge amount of work, and we have worked on this task as part of the ActivePlatform team for several months. The new billing type assumes that, for example, if we order a subscription on the 15th, then all invoices are issued on the 15th, every month.

But it has a lot of write-off conditions, because all resellers have downstream resellers who report to them. There are plans, subscriptions, money, postpaid, prepaid, intervals that can be paid for, intervals where the subscription is suspended, and if you pay, it will be continued. In general, there are a lot of nuances. And each vendor still counts money and issues invoices in its own way. If the accounts in the company and from the vendor did not agree, respectively, this is a problem. Therefore, when setting up billing types, such things need to be tested many times.

Technology stack

• Ruby, Rails
• Redis, RabbitMQ, Postgres
• Faraday (a flexible HTTP client library, with support for multiple backends)
• Frontend: Vue, React, Angular, jQuery, and JS

It was very interesting to work with the Ancestry gem, which is a tree organizing gem. Ancestry allows the records of an ActiveRecord model to be organized in a tree structure, using a single, intuitively formatted database column. An entity can be both the root entity and the successor. That is, it does not connect different entities to each other, but connects the same entities into a tree and allows you to work with the tree.

Conventionally, there is a reseller at the country level, and all downstream resellers are subordinate to it. But there may be several sub-resellers in this country, and under them there may be another level of resellers. This wonderful gem helps to organize, exchange, and work with this structure.

Conclusion

We have enjoyed being a part of the ActivePlatform team and working with them on such a complex and large-scale project. If you need to develop an integration system with external services or create a subscription system for your project, leave a message in the form below and we will contact you to discuss your new project!