Queues #
A queue is a dynamic object, which created automatically based on an interface group. You have to remember if you do not define an interface group SKYVVA will create a default interface group with the name “skyvva_DefaultIG”. Each interface group will be created queues.
The element of the queue is the data packages from the interface group. If you have an interface group that contains two interfaces e.g. account and contacts the data packages will contain data of these two interfaces. If in an interface group e.g. Opportunity_IG you only put one interface e.g. the interface opportunity into the group then the data package resulting in this queue is only the object opportunity.
This picture shows the relationship between queue, attachment in the working basket and the resulting messages after processing the attachment.
The rule is that for an interface group a queue is created at runtime with a specific name from the SKYVVA engine. The relationship between the interface group and the queue is a 1:1 relationship. For one interface group, there will be a queue. If you don’t create an interface group for your integration then the SKYVVA engine will use the default interface group “Skyvva_DefaultIG” and create automatically the queue with the name <IntegrationID>-EO_ Skyvva_DefaultIG for example ” a0IA0000002GZ8dMAG-EO_Skyvva_DefaultIG”. All interfaces belonging to the integration
Queue details #
This documentation will be described more in detail about queue handling. The processing message has generally done in queues because of these advantages:
– Keeping order of arriving data
– Prioritize of queue
– Parallel processing of queues
– Stop / Start queue for administration purpose
The queue name derived from three information:
– Integration Id
– Interface group Id
– Interface Id + {EO, EOIO}
There are two types of queues, which are EO and EOIO. This property is inherited from
the interface group.
The queue will inherit the following property from the interface group:
- Type e.g. EO or EOIO
- Priority e.g. High, Medium or Low
The further queue will have a status like shown on this screen.
Note that you cannot define a queue like define an interface group or integration group. The queue is a dynamic object and will be created from the runtime of SKYVVA. The naming convention for the queue is as shown above.
You will have two types of queue e.g. EO- and EOIO-Queue. This property is inherited from the corresponding definition of the interface group. This property has an impact on how to queue will be processed. For EO-Queue, for example, the order of the incoming data e.g. attachment is not important. Therefore, the element of an EO-Queue can be processed in parallel between different scheduler runs.
This is for example not allowed for an EOIO-Queue. Here if the EOIO-Queue EOIO_X got failed then the processing of the whole queue is stopped and its status will set to “Hold”. For an EO-Queue the processing is not stopped. The EO-Queue just gets a temporary status “Failed” but the next processing will overwrite this status e.g. to “Ready” or “Failed” again depending on the result of the processing by the worker.
Queue inherit the priority from their interface group and thus a queue will be a Prio-High, Prio-Medium or Prio-Low Queue. The processing is aware of respecting the priority of queue and therefore will be processed queue with priority High before Medium and Medium before Low.
In general, the processing of data packages within a queue X is sequential. If you want to have parallel processing of queues you have to define more than one interface group within an integration. Remember that you already have at least the SKYVVA default interface group but you should organize and create new interface groups/queues for your integration. Do not rely on the SKYVVA default queue because this is not a good way.
EO-Queue
When the interfaces do not relate to each other and does not have depending sequence then you can define this group as an EO-Group. This queue is to group different interfaces with a small amount of data together, to improve the performance of processing.
EOIO-Queue
This type of queue is the opposite way of the EO-Queue. EOIO-Queue is the interface account and contact. In Salesforce you have to split the data into two different tables e.g. into account and contact table. If you post the contact before account than you will get an error because the contact references an account. The account is the parent of the contact and therefore has to be posted before.
To achieve this goal you have to define an interface group e.g. “Acccount_Contact” with the property type = EOIO. Then specify the sequence number 1 for the interface account and the sequence number 2 for the interface contact.
Parallel processing of the queue
Parallel processing is possible because the data in different queue is not related to each other and therefore can be posted independently. We have in the best case five apex jobs as a worker to do parallel processing. The maximum parallelization is 5 due to the SF limit of
5 batch apex job.
Status of the queue
This section will be explained about the status of queue and how each status works.
There are 6 status of queues.
– Ready
– Worker
– Running
– Failed
– Hold
– Stop by Admin
Descriptions
1. Status Worker:- This status is a temporary status which is set by the scheduler. This status is a helping status to know that the scheduler has passed the data package/queue to the worker. When the worker starts to process the data package/queue it will change the status from “Worker” to “Running”.
2. Status Running:- This status is set by the worker. When a data package/queue is passed from the scheduler to the worker the status of this queue is “Worker”. Then the worker changes the status from “Worker” to “Running”.
3. Status Fail:- This status is set when processing a data package/queue got failed. This status is only used for the EO-Queue. For the EOIO-Queue this status is not used but the status “Hold”.
4. Status Hold:- This status is set when processing a data package/queue got failed. This status is only used for the EOIO-Queue. For the EO-Queue this status is not used but the status “Failed”. When the status is set to “Hold” then the processing of this queue is stopped because otherwise, you will create an overtaken of data.
5. Stop by Admin:- This status is the result of an admin action. An admin might want to stop the queue because of maintenance work.
Administration of queue #
The administrator can stop a queue so that it will not be processed by the scheduler. This might happen if the queue has accidentally too many entries and will take a long time to process.
To stop a queue, please follow the given steps:
– Open your integration, Click on batch control board
– Select the “Queues” tab.
– Click on the “Stop” button to stop the queue.
– The system will ask you again for the confirmation. If you really sure that you want to stop the queue just click OK.
As you can see from the above screenshot, the link has been changed from “Stop” to “Start”. The status also changed.
Where to use a queue? #
The queue is used in Batch processing.