Home > Help center > Billia Instructions > Billia engine Workers and Crons

Billia engine Workers and Crons

Cron - is executed in the system at specific time frames and doesn’t require any preset data to work with.

Worker - requires preset data, body, title, template, to work with.

[Cron] AutoRenew

Used to renew all purchases that meet the AutoRenew Cron criteria.

These criteria include:

  • The Catalog product billing types has to be renewable or continuous only;
  • The Customer service statuses have to be active, expired, suspended or redemption only;
  • The status of the Catalog Product has to be active or hidden only;
  • The setting “auto renew” for the specific Customer product has to be enabled;
  • The setting “next due date” of the Catalog product has to coincide with the last 24 hours, i.e. the customer product in question is within 24 hours from its auto renewal as set in the settings of its Catalog product.

In the case all criteria has been met, the AutoRenew Cron places a new purchase for product renewal for the same time frame of its initial purchase. I.e., if the product had been initially purchased for the amount of 12 months, the AutoRenew Cron will renew it for the same amount of time.

Additionally, the Cron automatically creates a label titled automated - yes in the respective purchase for the renewed Customer product.

[Cron] AbandonedCart

Tracks all AbandonedCarts and sends emails to those customers to remind them they have items left in their shopping carts and to complete their purchase.

The criteria that need to be met for this Cron to work properly are:

  • The product in the cart needs to be of Order type new, renew or transfer;
  • The product to have been added to the cart within the 24 hours prior to the execution time of the Cron.

In the case these criteria are met, the Cron AbandonedCart will select all AbandonedCarts and will trigger an Eventor Event called Billing\\V1\\CartAbandoned::after[1day]. This chain of actions then prompts the Eventor to send emails to the customers with carts containing abandoned for 24 hours items.

Moreover, the Cron AbandonedCart also creates a Promo code which is sent in the said email to the customers. The Promo code has the prefix cart- and provides a discount to all abandoned items in the cart as a percentage in the amount of the configuration of the business’s Affiliate system for Level 1 (lowest level). This means that the Cron AbandonedCart generates dynamic discounts based on the business’s certain Affiliate setups for services.

[Cron] BilliaDatabaseFieldTrigger

Used to manage Date and Time fields and to trigger various Eventor Events.

Note: This is an additional script that is designed to trigger Events that are custom. In every other case, Billia becomes the trigger of the Event.

Example:

The business wants to send an email message to their customers on the fifth and seventh day after payment has been made for a service they’ve purchased. The Eventor Event will send the actual email, but the Cron BilliaDatabaseFieldTrigger will trigger that Event.

The Cron will first receive the information on the desired resource (order), then which field to take into account (date_paid), and finally what the exact interval should be. This together would represent the payload the Cron should possess.

{ "resource": "Database\\V1\\OrderPurchase", "modifiers": { "date": [ "+5 days", "+7 days" ] } }

[Cron] CleanObsoleteEventsFromDB

Used to clear and delete old activity logs from the system for a specific time frame. That time frame is configured in the system and matches the business preference on the matter.

The Activity Log generates a large quantity of data, and also plays the role of a security log, for which it cannot be kept indefinitely in the system.

Each business decides for themselves how long their Activity Log should be kept for. The Cron CleanObsoleteEventsFromDB can then be configured as per those preferences.

[Cron][Non-Default] CloudDateAmountSynchronize

Note: This is a custom Cron designed for OnApp. This makes it a Non-Default Cron, which means that if OnApp is not used, then this Cron is not needed as it is not a default for Billia.

Used to dictate the behavior of the Billia Cloud in various aspects. The Cron selects all active Clouds, counts the number of data centers that each user has, concludes which ones are with depleted funds or need to be suspended, monitors the user’s Wallets and takes further actions based on the available amount in those Wallets.

The Cron CloudDateAmountSynchronize is directly responsible for those system actions taken on user’s Clouds, which are basic Billia Cloud functionalities. To best understand what these functionalities are, please see the article on How the Billia Cloud works.

[Worker][Non-Default] CmailProAccountImport

Note: This is a custom Worker designed for CmailPro. This makes it a Non-Default Worker, which means that if CmailPro is not used, then this Worker is not needed as it is not a default for Billia.

Used to create bulk accounts for CMailPro at once. The Worker defines and generates the accounts, all at once.

Example:

Can be used in the case an Enterprise business needs to import multiple email accounts all at once. This Worker will complete the task in bulk with great concurrency.

For more information you can see our article on Migrating 3000 emails per second.

[Worker][Non-Default] CmailProAccountImportInitializer

Note: This is a custom Worker designed for CmailPro. This makes it a Non-Default Worker, which means that if CmailPro is not used, then this Worker is not needed as it is not a default for Billia.

Used prior to the work of Worker CmailProAccountImport.

Worker CmailProAccountImportInitializer receives a list of all the CMailPro accounts that need to be created. Then it calls on the Worker CmailProAccountImport to actually create the accounts by initializing its process.

[Cron] DatabaseIndexInElastic

This is a Cron from the Search module, that can be shared and used in various other softwares. It’s purpose is to receive and review the list with all Resources that have to be indexed in ElasticSearch. Works together with Cron ElasticCache.

For Billia, these Resources include - customer_product, catalog_product, customer_product_option, etc.

After these Resources are presented to the Cron DatabaseIndexInElastic, it starts to review each one separately.

Example:

In the case the Cron DatabaseIndexInElastic takes for review the Resource user, it proceeds by then accessing the database, selecting all user_ids, and triggering an Eventor Event, which will for, each Resource and Entity, raise a task for indexing to the next Cron - ElasticCache.

[Cron] ElasticCache

Used to perform the indexing process on the selected by Cron DatabaseIndexInElastic Resources. This Cron has two work methods - direct and proactive.

The Proactive method involves the Worker ElasticCache selecting from the database the entire Entity of each provided Resource by ID, and adding it to ElasticServer.

The Direct method involves the Worker ElasticCache already receiving the entire Entity’s information and using it to index it. This method is with the purpose of faster data indexing in ElasticSearch in the case the Entity data is already received.

[Worker] DomainAvailability

A Worker designed for the Shopping cart. It’s purpose is to additionally verify that the domains that customers want to purchase, and put in the Shopping cart, are truly available. This Worker is needed so that customers don’t manage to bypass the Shopping cart security, even unwillingly, and buy an already registered domain.

The Worker gets triggered by a domain name being added to a customer’s Shopping cart. Then it verifies the domain is not already registered in the Registrar used.

In the case the domain name isn’t actually available, then the Worker DomainAvailability marks that domain as not available and denies the purchase.

[Worker] DumpActivityFromRedisToDB

Another Worker that manages the Activity and Security Logs of the system. In order for the Activity Log to get processed faster, it doesn’t get loaded in the database in real time.

It rather gets stored in the Redis Storage where the Worker DumpActivityFromRedisToDB periodically selects all current records and afterwards loads them asynchronously in the main database.

The purpose of this Worker is to speed up the processing of the Activity and Security Logs and to keep the main database from overloading with Logs’ data.

[Cron] FinancialDocument

Used to register and generate all financial documents in the system. These financial documents include Proformas, Invoices, Credit and Debit notes.

The Cron FinancialDocument will analyze all purchases in the system, their payment status (paid=0 or paid=1), and what type of document they require to be generated. That type is dictated by specific criteria. The

To see what criteria prompt the various types of financial documents, please see this respective article on Document Types.

Example:

A Proforma type of document can be only generated if a) there are no previous proformas for this purchase, b) there is no invoice already generated and c)if the payment hasn't been made yet.

[Worker] GenerateDocument

This is a Worker belonging to the Document Manager component.

Tip: The component Document Manager is a vital and integral part of Billia. Nevertheless, it can also be purchased separately from Billia.

This Worker’s purpose is to generate already registered financial documents as .pdf files. Each of the generated by the Cron FinancialDocument documents have a unique document_id. The Worker GenerateDocument receives that document_id, then fetches the data it needs such as template, and applies it along with all variables needed. Finally it generates the document .pdf and stores it in the S3 Server.

[Worker] Marshroutizathor

Used for backward compatibility. Is the predecessor of AppCell. Currently is located in the AppCell bridge module.

Currently, the [Worker] Marshroutizathor initializes integrational processes through AppCell, where, if they cannot be carried out due to unsupported plugins, they are rolled back to AppCell.

[Worker] Notification

A generic Worker used to distribute various notifications to the specific Notification[types] Workers.

When a notification is up, the Worker Notification processes it, prepares and puts together its needed data, as provided by the main software, and sends it to the specific channel(s) - Worker Notification[type]. In some instances a notification may need to be distributed through two or more channels.

[Worker] Notification[type]

An extension to the main Worker Notification. Each Worker Notification[type] is a specific notification channel, e.g. sms, customer, email, custom, etc.

Their purpose is to send the notification through their dedicated channel. These channels need to be set as separate workers in order to be usable for notifications.

[Worker] NotifyOrchestratorStatus

The Billia engine uses the Circus Process and Socket Manager for the management of the Workers and Crons.

The Worker NotifyOrchestratorStatus is used to execute tasks towards the Circus services for all Workers and Crons in all containers of the system.

The Worker NotifyOrchestratorStatus processes various commands, which it then can execute towards the Circus in case they are needed. E.g. - for the Circus to restart all Workers.

The commands that the Worker NotifyOrchestratorStatus supports are:

List - to list all Workers;

restart-all - to restart all Workers;

restart - to restart a specific Worker;

globaloptions - restores the settings for the specific Circus;

stop-service - to stop the selected service;

start-service - to start the selected service**.

[Cron] OrderPay

Used to track all purchases that are in the order status pending, the amount that has been paid for that purchase is larger than 0 and the payment status is paid=0. This means the purchase has been marked as unpaid while the amount for it has actually been paid.

In these cases the Cron OrderPay processes the purchase and marks it as paid, or paid=1 if the amount paid is equal or higher than the price of the purchase.

[Cron] OrderPaid

Used to track all orders of a single purchase that are in the order status pending and their payment status is paid=1, which means paid. Then it checks if that entire purchase is actually fully paid for, which requires all of its orders to be fully paid for.

Note: One purchase consists of one or more orders.

If at least one order of the purchase is not paid for, the Cron OrderPaid will not act.

If all orders of that purchase are paid for, the Cron OrderPaid will then perform a fraud check on that purchase and will also see if the user who placed the purchase is in active status.

If the user is indeed active, the Cron OrderPaid will change the order status of the purchase to approved.

If the user is detected as inactive, the Cron OrderPaid will send an email prompting the user for account activation.

Note: An inactive can place purchases but the services ordered will not be provisioned until the user account is activated.

[Cron] OrderProcess

Used to select all orders that are in the order status approved and then checks if the ordered product/service has been fully configured by the user.

Note: A new feature in Billia 4.0 dictates that certain products/services, when purchased, can be allowed to not be fully configured right away by the user. The configuration consists of all required by the system information.

If the product/service has been fully configured by the user, the Cron OrderProcess will send a request for provisioning to the [Worker] Marshroutizathor and mark the order status to processing.

Note: After AppCell processes the order, it changes its order status to provisioned.

If it has not been fully configured yet, the Cron OrderProcess will change the order status to configure and will not send a provisioning request. It will instead be taken for processing by the Cron OrderConfigure(next on the list).

Under the Cron OrderProcess is where the product/service is initially created. It starts with a service status pending, in the case the product/service has already been configured, or a service status configure, in the case the product/service has not been configured yet.

[Cron] OrderConfigure

Used to track all orders that are in the order status configure and checks if they have already been fully configured by the user.

Note: A new feature in Billia 4.0 dictates that certain products/services, when purchased, can be allowed to not be fully configured right away by the user. The configuration consists of all required by the system information.

The said order will remain in order status configure until its product/service has been updated with the required information.

When it is, the Cron OrderConfigure will send a request for provisioning to the [Worker] Marshroutizathor and mark the order status to processing and the service status to pending.

[Cron] OrderActivate

Used to track all orders that are in the order status provisioned and sets them in the order status activated.

At the same time it calculates all relevant service dates for the respective product/service.

During this Cron’s processing time is where both the order and its product/service become activated.

[Cron] ProductExpire

This Cron tracks the date_expire of products/services that are in the service status active and changes them to expired when it’s time.

[Cron] ProductSuspend

This Cron tracks the date_suspend of products/services that are in the service status active or expired, and their billing type to not be “one time”. If these criteria are met, the Cron ProductSuspend will set these products/services in the service status suspended when it’s time.

[Cron] ProductRedemption

This Cron tracks the date_redemption of products/services that are in the service status expired or suspended, and sets these products/services in the service status redemption when it’s time.

This status prompts for a higher renewal price of the product/service.

[Cron] ProductTerminate

This Cron tracks the date_terminate of products/services that are in the service status suspended or redemption, and sets these products/services in the service status terminated when it’s time.

At this point the product/service can no longer be renewed and ownership is lost.

[Worker][Non-Default] RegistryBgCheckAvailability

Note: This is a custom Worker designed for RegisterBG. This makes it a Non-Default Worker, which means that if RegisterBG is not used, then this Worker is not needed as it is not a default for Billia.

Used to check RegisterBG if a certain domain is actually available.

[Worker] RemoveExpiredAccessTokens

Used to remove all tokens that have expired by tracking the access_token_date. With security purposes in mind, this Worker will remove expired tokens 24 hours after their actual expiry.

[Worker] SynchronizeCustomerProduct

Used to select all customer products that are from the same Module. Once all these are selected, the Worker synchronizes their data using an AppCell synchronization functionality. This means it will obtain the latest information to date from the specific provider and update the main Billia database.

[Worker] Transfer

Used to track all domains, that are Transfers to the Billia system, and updates their transfer status accordingly during the entire transfer process and once it is completed.

[Worker] TriggerEvent

The main Worker for the Gear software. Used to manage the Eventor and all of its processes - all triggered events, the attached Listeners, the data that needs to be processed and delivered, etc.

[Worker] UsageBased

Used to track all usage-based products/services in the system whose next due date is the same day (today). It then sends a request for their Renewal.

[Cron] WalletBalanceChecker

Used to check if the Credit Limit of a user has been exceeded. It tracks all users who have a Wallet Balance below 0. For those, this Cron sends two email messages:

  1. In the case that a user has a negative Wallet Balance in the amount of half their Credit Balance - it sends a Warning email.
  2. In the case that a user has a negative Wallet Balance in the amount of 90% of their Credit Balance - it sends a Critical email.

[Cron] WalletPay

The main Cron responsible for completing users’ Wallet queries. It selects all unpaid Wallet requests with a status canceled. It then checks if the user’s Wallet has a larger amount than the price of the purchase, and if so - pays the purchase.

[Cron] WalletRecords

Used in the cases when there are too many Wallet transactions being processed at the same time. To progress better and faster, this Cron tracks all transactions that are in the status waiting, processes them and marks them as completed.