Home > Help center > AppCell > AppCell - Details & Information

AppCell - Details & Information

What is AppCell

AppCell is an integrative software incorporating a plugin-based structure through various manageable vendor micro-software. Called “cells”, these micro-software are designed to execute complex hybrid decisions together. Performing hybrid decisions is an innovative functionality, which ensures diversity and process advances in eCommerce offered products.

Additionally, AppCell includes a new and innovative Application Packaging Standard. The software can be integrated into a main/centralized system to act as a service standardizing application and unify the communication between itself and the main platform. In other words - it provides businesses the use of third party vendors for selling purposes, where AppCell standardizes their processes and allows them to work faster and more efficiently together.

AppCell features

AppCell incorporates various and useful features:

  1. It possesses a database of configured cells of various services/vendors. These cells can be combined to seamlessly work together in a hybrid plugin.

  2. It is designed to be language-agnostic and capable of working with various centralized systems and plugins, no matter the programming language they would be based on (PHP, Java, Python, JavaScript, C++, etc.). AppCell operates through intermediary mini-software which effortlessly translate and support the entire communication process.

  3. It standardizes the various service/vendor cells. Due to the fact that each vendor carries out its processes differently, AppCell can equalize their operation patterns and unify their communication with the main software. This means - one UI for management purposes, where vendors work simultaneously in the same manner, through AppCell’s specific schemas for standardization. These schemas are integrated parts of those vendor cells. This puts the vendor cells to work in one single framework, which pushes a unified and standardized way of system processing, where the type of the parameters is accepted as the same for all cells.

  4. It doesn’t require any hardcoding, which makes it flexible for integration and use.

  5. It ships the individual UI of all services, which makes the transition between plugins’ execution effortless.

  6. It incorporates error-handling and retry strategy. In the event of an error during an AppCell execution process, the software can pull the cache from all successful steps prior to the error and initiate a retry strategy. This way the software doesn’t lose any processing progress and doesn’t excessively load the main system.

  7. AppCell supports software information generators, which can be reused.



    Generate {{username}} and {{password}} for the creation of a cPanel account. Payload will display:

    Username: generator(cPanelUsernameGenerator, {{option.username}}), Password: generator(cPanelPasswordGenerator)


  8. Cells aren’t actually a part of Billia and AppCell can be integrated into any other main software for it to benefit from all the Plugins.

  9. Administrators can modify the Plugins and their actions’ payload, without risking damage to the programming code.

  10. It includes JSON schema verification. AppCell will examine every Cell’s I/O to confirm whether it complies with the standard.

  11. SDK, Proactive triggers, Unified error system, Multi-server support, Retry Strategy, etc.

AppCell Components

AppCell consists of five main components:

  1. Plugin An abstract configuration of required workers and actions, which it executes. It It is comprised of one or more Cells as per the purpose it follows. Plugins are managed by the vendor’s Control Panel, created by an Administrator, and used for communication with external software. Plugins represent the business logic of the company.



    If a plugin implements a suspendible interface, that means it has to support suspend/unsuspend actions. These will be available to be called by your centralized software or Billia.

    All plugins have two main features:

    • What interfaces or schemas it implements and what actions it supports;

    • What payload scope it requests from the main software.


      The Plugin ResellerClubCell requires a Customer Profile to build Domain Contacts.


  2. PluginAction

    Represents basic actions of a Plugin in their respective sequence/order, which are recognized by the main system. They are mostly carried out as pipeline actions - flows of actions that follow each other if specific conditions are met.



    "implements": [
    "https://repository.appcell.io/core/service.schema", "https://repository.appcell.io/core/suspendable.schema", "https://repository.appcell.io/core/availability.schema", "https://repository.appcell.io/core/usage.schema" ]


  3. Cell

    A micro-software developed to connect a third-party vendor to standardized AppCell actions. It will translate Billia/AppCell commands to vendor-specific business logic. The cell has very specific to its purpose resources, where it ships all of them for the necessary task. At the same time one Cell can preconfigure multiple Plugins by providing its own logic. Cells connect to the central Message Queue (MQ) and receive their tasks from there.



    Creating a product from type cPanel will be translated to code that will:

    1. Find a free cPanel Server;
    2. Generate suitable username and password;
    3. Create an Account;
    4. Set quota;
    5. Attach a Dedicated IP.


  4. Resource

    Represents a part of the Cell (REST, RPC). It is a developer unit comprised of functionalities and a fundamental concept in any RESTful API. A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. The resource has only a few defined standard methods that correspond to the standard HTTP GET, POST, PUT and DELETE methods.

  5. ResourceAction

    The action of a resource. It could be to create, update, edit, delete, etc. REST APIs use CRUD, but RPC ones can also have custom actions created.

Plugin vs. Resource

The difference between a Plugin and a Resource is fundamental and centralized in their logic:

  1. The Plugin represents the business logic - the logic that is defined by the business/company. It is the underlying processes within a program that manage the communication between the database and the end user interface. Business logic is more correctly the code that defines the database schema and the processes to be run. It contains the specific calculations or commands needed to carry out those processes. Тhe business logic works behind the UI, which is what the customer sees and interacts with, to carry out actions based on the input values.

  2. The Resource represents the technical logic - the logic for the business action at hand which includes objects that possess characteristics such as type, associated data, relationships to other resources, and a set of methods. Resources are the detail pieces that construct a service/product.

In the process of a plugin completing its action, there is a specific sequence that is followed, where different actions may apply to the plugin itself or a resource.



The company “Xyz” needs to purchase hosting. Their plugin “Xyz” sets the plugin action “create” to purchase the hosting.

But, in order for that plugin to complete its plugin action, other actions, dictated by the business logic, need to be completed first. These actions are towards specific resources and could include “create=user”, “activate=user”, “place=order”, and anything else that may be important as a resource action for that business in that specific scenario. In this case - purchasing a working and configured hosting.

Once all resource actions are completed, they are combined under the one plugin action “create=hosting”, and the plugin “Xyz” completes it.


Cells and Plugins

One Cell can ship many plugins. This means that the Cell can preconfigure multiple Plugins by providing its own logic.



The Cell “OnApp” can ship the Plugin “Cloud”, the Plugin “VPS”, the Plugin “DNS”, etc.


But at the same time, a single Plugin can use multiple Cells.



During the plugin action “create” for the Plugin “Cloud”, there is a specific sequence of actions that follow: first is called the Cell “OnApp” with action “create=VS”, after that is called the Cell “Ansible” with action “install”, and then the Cell “CPanel” is called with action “provision=account”.


AppCell Plugin details

The AppCell Plugin is the most advanced component of the software. It is not hardcoded and doesn’t require any additional configuration once developed and integrated into AppCell. This means that the Plugin is easily reusable.

The Plugin is comprised of one or more cells. Due to the language-agnostic capabilities of AppCell, plugin development costs are low and they can be developed in any programming language. The only requirement is to have an AMQP communication library, which is available for every such language.

Moreover, the software’s error-handling and retry strategy functionality is assisted by the fact that the AppCell plugins have multistep provisioning.


AppCell cannot operate on its own. It must be integrated into a main system/platform - i.e. the one the business in question is operated by. On top of being language-agnostic, the software is also completely autonomous in terms of network communication between the individual components of that system. It doesn’t require for it to be additionally configured to comprehend any AppCell-specific requests or to undergo changes in the programming code. The central system is not required to understand or operate the separate components of AppCell, either. This makes AppCell compatible with any type of centralized eCommerce system.

How AppCell works

AppCell communicates with the central system through the AMQP protocol. When AppCell-related requests are generated, the system supplies them as predefined commands to the AppCell software. In return AppCell distributes these requests to the specific vendors (cells). AppCell then provides double confirmation that the data is a) the requested one for that specific cell, and that b) the data that the vendor cell returns is the one requested by AppCell.

Thanks to its core logic, AppCell is the only software that can read and execute such requests. That same core logic also incorporates specific schemas, through which the software can impel the vendor/cell to work with particular data. This is done in a way, strictly distributed by that schema.

The work process of AppCell:

  1. Once the request for software integration and use has been placed by Billia (per the request of a user), AppCell needs to provide a plugin and validate that the pipeline is available. The entire communication goes through a Message Queue (MQ).

  2. The Plugin itself is a configuration of the specific Cell(s) that need to carry out certain tasks. Thanks to AMQP, the Cells don’t need to be uploaded to a local server, as their location is not of importance. They can be called at any moment from any server.

  3. The Cells need to be first installed, in order for the Plugin to be configured. AppCell supports automatic Cell installation:

    3.1. AppCell receives four main Cell configuration files:

    • Appcell.json - basic information for the Cell;

    • Plugins.json - information for the final Plugin configuration;

    • Resources.json - all Resources the Cell supports;

    • Settings.json - information on the main software of the product configuration; includes all options and fields in the payload.

    3.2. These get uploaded to AppCell repository;

    3.3. The plugin is then configured and all of its PluginActions are created in the database;

    3.4. A final installation check on the Cell is performed.

  4. At the same time specific actions are carried within the Cell by its Resources. These include:

    4.1. Receiving the task at hand;

    4.2. Validating action for execution;

    4.3. Populating payload;

    4.4. Verifying conditions;

    4.5. Committing to schedule;

    4.6. Sending to MQ;

    4.7. MQ routes and processes the request; includes retry strategy in case of errors;

    4.8. If successful, the result is validated and acknowledged; if it is not, it returns an error.

  5. All Plugins incorporate PluginActions and Cell’s ResourceActions. These have a correlationid which indicates to AppCell whether the specific action is unique. When a correlationid is completed for the first time, AppCell stores all of its information and archives it in the database. This means it will return the same result in case the absolute same action is again performed, without the need to repeat the entire process.

  6. All Cells connect to the central MQ. Implementation is easy as the only required supported aspects are: reply messages of the queue, which AppCell sends as a replyto, and the sending of the correlationid.

  7. All action executions are monitored. This means that in case one of the processing steps fails, the system will not start from the beginning, instead it will retry the failed step and progress from there. In other words, all Cell output is saved in order for the cache to be generated.

  8. When all processes are completed and the Plugin is successfully configured a pipeline result is sent to Billia.

AppCell Benefits

AppCell provides numerous benefits for improving the business, the process of acquiring clients, system management, decreases business costs, and much more. It allows one software to communicate with multiple others without coupling, modification of the source code of the central software, or hard coding any plugins. It doesn’t raise any concerns in regards to possible problems on the low level integration of third party solutions. Additionally, it decreases the business’s go-to market time and its costs for software integration.

Industry issues solved by AppCell

AppCell is focused on improving the day-to-day work processes of companies in the hosting and software industries. The issues AppCell manages to resolve can save business time, man-power and development costs. The software also overcomes standard problems that occur during the creation of the actual programming code of the systems.

  1. Having only integrated a plugin-based infrastructure is not the ideal situation for most companies. When initiating a connection to an external vendor, issues can occur due to incompatibilities in the working processes and programming language used. This can lead to patched-up coding, loss of scope and concept of the software, development overtime, and higher costs. Moreover, no company can use a large number of vendor plugins, due to varying system processes, as there is no standardized way for them to work together.

    AppCell is language-agnostic and standardizes vendor cells, which bypasses the aforementioned problems.

  2. Other plugin-based software include hard coded plugins. This leads to compatibility limitations and further development issues. E.g. - in case a new plugin needs to be added or the central software to be modified/updated, the hardcoded plugins prove to be problematic. This results in errors, code complications, and functionality/system corruptions.

    AppCell’s plugins are not hardcoded and therefore don’t lead to compatibility or modification limitations or issues. They can be seamlessly transferred, transitioned, updated, removed, or added, without any risk for the centralized system.

  3. Processing errors can always occur during the provisioning process. Usually, this means that the entire process needs to be restarted, which often leads to more errors and system corruption.

    AppCell incorporates an error-handling and retry strategy functionality, which ensures that one error during the provisioning process will not corrupt the entire system or end result.