Skip to content

Scheduler

Scheduler Service

eComNow has a dedicated Scheduler Service that operates using a set of pre-scheduled tasks stored in the Tasks table, performing various operations as required.

To schedule a new task, you must first ensure that the task has already been implemented in Scheduler Service. If you plan to create a new scheduled task, you will need to provide its implementation within the Scheduler Service before it can be scheduled. Below is the list of already implemented tasks:

List of Implemented Task

Task Name Explanation
UpdateProductsInventoryAndCBPVendors This task perform inventory and product update for various vendors.
DeleteInactiveProducts This task delete inactive products for vendors
RefundUpdates This task send refund updates against orders
RebuildCategoriesIfNeeded This task rebuild the categories if required based on data available for vendor
eComNowClientsApiIntegrations This task operated based on data available in these table ecomnow_customer_integration...,
Boxout This task perform order product and inventory updated for Boxout client
UserNoLongerInPlatform This task identify users available in AWS but not listed in eComNow platform.
UserNotEnabledInAnyPlatform This task identify users that are not enabled in platform
UserNotLoggedInPlatform This task identify the user those are not loggedin platform in last 6 months.
PerformUserAudit This task perform the selected operation mentioned in above 3 tasks.
ApiStatusCheck This task operate based on api_status table and verify the expected and actual status of api

API

In order to perform the Crud operations, apis defined in ecom-api service, Those apis can be used to configure new tasks or enabled or disabled exiting tasks,

Task Details

UserNoLongerInPlatform

This task focuses on identifying users available in AWS Cognito but not found in the aws_user_view based on platform. The comparison of users in this task is performed based on the configured platform in the tasks table. On the AWS Conigto side, the attribute custom:platform is used for platform-level comparison. Users without this attribute are processed in the US scheduler.

Once the user data is compared, the user_audit table is populated. If a user is already identified as not available on the platform in current cycle, those users will be excluded from email notifications in the next cycle. These are some importent columns in user_audit table:

  1. Audit Type: This indicate the task which produces the current record
  2. Action: By deafult this action will be NONE. Post task will be using this cloumn to define its action. NONE mean othing to do.
  3. Plateform: This indicate for which platform user was created but not found in that platform now.

Post Action Task: To ensure the completion of the entire process, it is necessary to execute this task. This task will consider the action selected earlier and process it accordingly. Here are the details of all the supported actions within this task:

  1. Disable in AWS : This action will disable the user in AWS cognito
  2. Enabled in AWS : This action will enabled the user in AWS cognito
  3. DELETE from AWS : This action will delete the user in AWS cognito permanently
  4. Reminder Sent : This action will send remindedr to user, informing them about they havn't logined in system for last six months
  5. Delete from DB : This will delete user from Database
  6. Delete from AWS & DB : This action will delete user from both database and AWS cognito permanently

For more details please check with team.

Thanks