Systems Configuration & Restart

The Apply and Restart function applies all pending changes and restarts the XCore system. This causes ALL pricing and trading connections to be briefly disconnected.

Any change performed via the Pending Config component will require the “Apply and Restart” function to be applied and as such, it is advised that where possible, the real-time config component is used to make live changes.

The Verify function is a pre-restart check that the system performs to confirm, or verify, that there are no conflicts in the pending changes.

This can be used to check pending changes so that when the “Apply and Restart” is scheduled, it can be carried out quickly by minimizing unexpected errors.

The Verify function will NOT cause a restart of the system and hence will not disrupt any active connections.

The Reset function reverts all pending changes.

The Reset function will NOT cause a restart of the system and hence will not disrupt any active connections.

The Backup and Restore feature on the XCore Pending Config Component is designed to enable XCore users to roll back the XCore settings to a recent restoration point without any involvement from the PrimeXM Support team.

This feature is not recommended to be used for minor changes which can be corrected or reset easily on the fly. The last 5 XCore setting database (DB) backups can be accessed and identified by their timestamp.

Important Note: DB backups are saved and available to be restored within the current week. Every Saturday DB backups from the week will be erased.

The Restore feature is applicable to the following situations, please note the list is not conclusive and it is simply based on the most common use cases:

• Major changes on the Pending Config component where multiple component settings have been affected
• Scenarios which require time-consuming manual corrections
• Correction on the new settings not working as intended where an immediate rollback is the only solution

Following the below simple steps to restore:

1. Go to XCore Pending Config Component
2. Click on the “Backup” button on the Database panel above the Component list, this is an optional step to save the current settings as a backup.
3. Press “OK” in the Confirmation window to create a backup of current LIVE database

“Backup Operation Successfully Completed” message will be shown as a confirmation.

1. Select the desired database version from the drop-down list
2. Click “Restore”, a confirmation window will appear
3. Press “OK” to revert to the selected database of settings.

“Restore Operation Successfully Completed” message will be shown as a confirmation.

1. Any changes comparing to the current state will be shown in the “Rows Modified” field next to the relevant component.
2. Press “Apply & Restart” to apply all pending reverted changes and finalize the restoration procedure

Source Fields Example

In the Source Fields, conditions with “AND” relations are grouped by item type (i.e. component table, such as symbol, provider, provider config state etc). All fields defined within the same item type (component) should be true in order to trigger the actions defined in Target fields.

If conditions (fields) are defined within more than 1 item type (component table), all conditions should be met to trigger the actions. However, it is important to note that different item types (component tables) may not be interlinked. The below examples illustrate the difference:

Both conditions are within the same Item “Provider Config State”.
When the Provider is “Provider_1” AND State is “Disconnected”, automation actions will be triggered.

When the conditions are NOT within the same Item they are not linked: the Provider condition does not narrow the Provider Config State condition to “Provider_1”. The Portal does not save this rule, because a Provider Config State condition must filter both Provider and State (and a Connector Config State condition both Connector and Connected).

Target Fields Example

Target Fields are also grouped by “Item”.

Target field conditions belonging to different item types are independent of each other.

For example:

The Filter conditions in the following screenshot will have NO EFFECT on the Match/Non-match outcome which means that in this case, when the rule is triggered the “Liquidity Pool” for ALL Connectors under “Connector Account Settings” will be changed to “pool_2”

Instead, the item type should be the same so that only the “Liquidity Pool” for “trade/mt4” under “Connector Account Settings” will be changed to “pool_2”

Automation rules can be used to cause specific changes to the configuration based on predefined conditions.

Automation is configured in the Config Automation component of the XCore.

Add New Rule

1. Click “Add” to create a new rule
2. Choose a “Name” and “Description” for your new rule
3. Click “Next.”

Define Session Periods

This is when the automation should occur and acts as the first trigger. You can define multiple sessions if necessary – the automation will occur if any one of the sessions is true.

1. Click “Add.”
2. Select a day and time the automation should start
3. Select a day and time the automation should finish
4. Click “Save.”
5. Click “Next.”

Define Source Fields

This is an OPTIONAL step where additional triggers are defined. The system will check if ALL of the conditions in the source fields are true and if so, will execute the rule.

1. Click “Add.”
2. Item – select the component item for the trigger condition
3. Field – select the specific attribute which contains the filter value
4. Filter – define what value must be found to trigger the rule
5. Where necessary, Users can add multiple source conditions. Source conditions have an ‘AND’ relationship meaning all conditions must be true for the rule to trigger
6. Click “Save.”
7. Click “Next.”

Note: if no conditions are defined under the source field, the automation will automatically occur at the start of the session period and stop at the end. If conditions are defined, then BOTH session periods and source fields must be true to trigger the automation.

Define Target Fields

This is where users can specify the target/outcome for the automation rule. There are 3 possible value types: Filter, Match, and Non-Match; none of the value types are compulsory. See the Config Automation page for a description of these values.

1. Click “Add.”
2. Value Type – Filter – define which values in a specific component (item/field) the outcome should be applied to.
3. Value Type – Match – define the value in a specific component (item/field) to be updated if the session periods and source field conditions are met. Where Filter is defined, this will only apply to the filtered objects.
4. Value Type – Non-match – define the value in a specific component (item/field) to be updated if the session periods and source field conditions are NOT Where the Filter is defined; this will only apply to the filtered objects.
5. Click “Save.”
6. Click “Finish.”

Note: For each rule, it’s possible to define different outcomes in multiple components. Outcomes are grouped according to the “item” such that if a filter is set for one item and match/non-match for another, no filtration will occur. To define multiple outcomes in the same component, separate rules must be created.

In the below example, if the conditions in session periods and source fields are true, then change the Liquidity Pool assigned to “FIX_1_pricing” stream to “Failover_pool” else assign “Agg_pool. “

New rules will always be disabled by default. Always ensure the rule is Enabled for the automation to occur!

Failover Providers (aka failover LPs) are used as a ‘back-up’ Provider in case your main or current provider disconnects. In order to better manage risk caused by such disconnections and avoid disruption to pricing/trading streams, you can now use the XCore Config Automation component to ensure a seamless switch over to a backup Liquidity Provider.

Failover can be configured to happen automatically in the XCore using the Config Automation component.

The Failover LP can be set in different ways using the Automation Rules depending on the XCore setup configuration and preferences.

Cases

Case 1: Failover Liquidity Provider (Enable Failover LP)

With this case scenario if the Main Liquidity Provider has been suddenly disconnected the Failover Liquidity Provider will be enabled in the system in order to continue streaming. In order for this case of the Failover Provider automation rule to work the prerequisite is to have the failover provider assigned on the main liquidity pool that are using for client, and the failover is disabled in the system so that it will be working only in cases of sudden disconnections of the main LP.

To set it up this rule the below please check the below steps:

1. From the Config Automation component press Add button in order to start creating new automation rule and give accordingly a name and a description.

2. If needed you can define the time session when the automation rule should be active to check the system and act accordingly on the automation rule configuration.

Note: If the time session left blank the automation rule will be checking all the time the system and then act accordingly with the automation rule configurations.

3.Set the conditions in the Source Fields (if what should happen in the system) upon which it will trigger the automation rule.

The IF conditions in this which acts as triggers are:

4. Set the required actions in the Target Fields to be performed in the system if the automation rule is triggered.

The targets on which changes the automation rule should perform are:

Finally, press the Finish button to save the automation rule, please note that by default the automation rules are disabled when created, therefore you will need to enable the rule and save if you wish for the automation to become active and start monitoring the system.

Revert back automatically to the use of the Main Provider once it’s connected back.

Once our Main Provider is connected back again we would like to use again, to ensure this we have created a second automation rule which in case it detects that our Main Provider is connected back again in the system then it should disable the Failover provider from the provider component leaving only the Main Provider to work.

1. Created a new automation rule and give accordingly a name and a description.

2. You can either set up a specific time session for the automation rule to define when it should be checking the system in order to act accordingly or left blank which will mean that it will be checking the system all the time.

3. Set the up the trigger (IF condition) accordingly to which the system will be checking the system in order then to trigger the automation rule.

4. Set the required actions in the Target Fields to be performed in the system if the automation rule is triggered.

The targets on which changes the automation rule should perform are:

Finally press the Finish button to save the automation rule, please note that by default the automation rules are disabled when created, therefore you will need to enable the rule and save if you wish for the automation to become active and start monitoring the system.

Case 2: Failover LP (Assign Failover LP on the Main LQ Pool)

With this case scenario if the Main Liquidity Provider has been suddenly disconnected the Failover Liquidity Provider will be enabled in the system in order to continue streaming. In order for this case of the Failover Provider automation rule to work the prerequisite is to have the failover provider is enabled in the system always but without streaming to any client and to be assigned on the Main Liquidity Pool that is used for client which will replace the main provider assigned on the liquidity pool with the failover provider.

To set it up this rule the below please check the below steps:

1. From the Config Automation component press Add button in order to start creating new automation rule and give accordingly a name and a description.

2. If needed you can define specific time session when the automation rule should be active to check the system and act accordingly on the automation rule configuration.

Note: If the time session left blank the automation rule will be checking all the time the system and then act accordingly with the automation rule configurations.

3. Set the conditions in the Source Fields (if what should happen in the system) upon which it will trigger the automation rule.

The IF conditions in this which acts as triggers are:

4. Set the required actions in the Target Fields to be performed in the system if the automation rule is triggered.

The targets on which changes the automation rule should perform are:

Finally press the Finish button to save the automation rule, please note that by default the automation rules are disabled when created, therefore you will need to enable the rule and save if you wish for the automation to become active and start monitoring the system.

Revert back automatically to the use of the Main Provider once it’s connected back.

Once our Main Provider is connected back again we would like to use again, to ensure this we have created a second automation rule which in case it detects that our Main Provider is connected back again in the system then it should reassign on the Main Liquidity Pool to use the Main Provider that we want to have.

1. Created a new automation rule and give accordingly a name and a description.

2. You can either set up a specific time session for the automation rule to define when it should be checking the system in order to act accordingly or left blank which will mean that it will be checking the system all the time

3. Set the up the trigger (IF condition) accordingly to which the system will be checking the system in order then to trigger the automation rule.

The IF conditions in this which acts as triggers are:

4. Set the required actions in the Target Fields to be performed in the system if the automation rule is triggered.

The targets on which changes the automation rule should perform are:

Finally, press the Finish button to save the automation rule, please note that by default the automation rules are disabled when created, therefore you will need to enable the rule and save if you wish for the automation to become active and start monitoring the system.

Case 3: Failover LP (Failover LQ Pool on the stream and execution)

With this case scenario if the Main Liquidity Provider has been suddenly disconnected, the connector's stream and execution are switched to a liquidity pool that contains only the Failover Liquidity Provider. In order for this case of the Failover Provider automation rule to work the prerequisite is to have the failover provider enabled in the system at all times and assigned as the only provider of a separate liquidity pool (Failover_LP_Pool).

To set it up this rule the below please check the below steps:

1. From the Config Automation component press Add button in order to start creating new automation rule and give it a name and a description.

2. If needed you can define the time session when the automation rule should be active to check the system and act accordingly on the automation rule configuration.

Note: If the time session left blank the automation rule will be checking all the time the system and then act accordingly with the automation rule configurations.

3.Set the conditions in the Source Fields (if what should happen in the system) upon which it will trigger the automation rule.

The IF conditions in this which acts as triggers are:

4. Set the required actions in the Target Fields to be performed in the system if the automation rule is triggered.

The targets on which changes the automation rule should perform are:

Finally press the Finish button to save the automation rule, please note that by default the automation rules are disabled when created, therefore you will need to enable the rule and save if you wish for the automation to become active and start monitoring the system.

Revert back automatically to the use of the Main Provider once it’s connected back.

Once our Main Provider is connected back again we would like to use again, to ensure this we have created a second automation rule which in case it detects that our Main Provider is connected back again in the system then it should reassign on the Main Liquidity Pool to use the Main Provider that we want to have.

1. Created a new automation rule and give accordingly a name and a description.

2. You can either set up a specific time session for the automation rule to define when it should be checking the system in order to act accordingly or left blank which will mean that it will be checking the system all the time.

3. Set the up the trigger (IF condition) accordingly to which the system will be checking the system in order then to trigger the automation rule.

The IF conditions in this which acts as triggers are:

4. Set the required actions in the Target Fields to be performed in the system if the automation rule is triggered.

The targets on which changes the automation rule should perform are:

Finally press the Finish button to save the automation rule, please note that by default the automation rules are disabled when created, therefore you will need to enable the rule and save if you wish for the automation to become active and start monitoring the system.

New rules will always be disabled by default. Always ensure the rule is Enabled for the automation to occur!

The Config Automation component can be configured to automatically switch between markup profiles based on predefined conditions. This means that client markups and execution settings for orders can be automatically varied at certain times of the day.

For example, the system can automatically increase markups during market open and market close or during a specific planned news event.

Alternatively, users may wish to improve execution for clients during market open/close by absorbing slippage and hence choose to automatically assign “ACCEPT” spread_exec at specific times.

It is advised to have multiple markup profiles which the system can automatically switch between rather than automating changes to specific fields in current profiles.

The below guide will explain how to automatically switch between markup profiles based on predefined time periods.

How to Automate Scheduled Markups

Add New Rule

1. From the Config Automation component, click “Add”
2. Specify a Name for the new rule and add a description about what the automation rule will do
3. Click “Next”

Define Sessions

4. Click “Add”
5. Define the times that the automation should run. In this case the markup profile will be changed at FX market open/close
6. Click “Save”
7. Click “Next”

Define the Conditions Which Should Cause the Change

In this example, the only condition is the time period already defined in steps 4-6. If you wish to define filters for further conditions you can do so at this stage. For more information on defining “source fields”.

Define the markup profile to be assigned

8. Click “Add”
9. Under Value Type select “Match” to define the markup profile which should be assigned at the time period specified in step 5. You should do this for both the Connector Stream (pricing) and Connector Account (trading)
10. Click “Add”
11. Under Value Type select “Non-match” to define the profile to revert to if the time is not within the period specified in step 5. Again, you will need to do this for both the Connector Stream (pricing) and Connector Account (trading)
12. Click “Save”
13. Click “Finish”

The holiday sessions can be set in advance in the XCore which would apply without manual interaction of humans by using the Configuration Automation component for controlling the operating time of a financial instrument (symbols)  on certain minutes, hours, days.

In order to achieve this first head on to the Configuration Automation component and press Add which will open the wizard to create a new Automated rule, decide a name for the automation rule and description if needed.

The next step needs to define the time (sessions) when the automation rule should apply in the XCore system. in other words during the defined time period the symbol (s) should be inactive for pricing and trading.

The Source Fields step can be ignored for the Automatic Holiday Sessions as it does not require a trigger but only defining the time sessions for when you wish to disable the symbols in the XCore.

Last you need to set the end result you wish to apply on specific settings (component) such as disable the symbols at the time sessions configured in one of the previous steps and then automatically enable them once the time sessions configured has passed:

Note: The Non-match specification is needed in order to enable the symbols automatically once the time sessions defined has ended

In order for the rule start working don’t forget to enable and save the specific rule that has been configured.

By using the config automation tool of the XCore it is possible to configure automatically expiring products such as CFDs that follow future contracts.

In order to use the automation rules for expiring products as a prerequisite to successfully set it you must have already created the generic symbols and they are active in the XCore.

For example, you already have created the generic symbols:

• WTI.XX
• WTI.YY

Now by configuring properly the automation rule you are able to set for future the symbols when the contract will be changed to change automatically the in the XCore the configuration required to successfully subscribe.

From the Configuration Automation component press Add button which will open the wizard to create new automation rule and add the name for the rule and a description.

In the next step of Session Periods will need to define when the rule should apply/working in the XCore.

For example for the expiry product WTI.XX which we need to be applied on 01/04/21 and will be an active contract until the end of month on 30/04/21 the session period will be set as: Custom 01.04.2021 12:40:00 Custom 30.04.2021 22:00:00

Note: The time session configuration is done in UTC time therefore you will need to consider different timezones.

The Source Fields part can be skipped since there is no action needed to be recorded as a trigger to make the required change because the trigger for expiry products would be the time session defined in the previous step.

Finally in the Target Field step need to define the end result which we wish to be implemented in the XCore. For the expiry products the required changes would need to be done on the Provider Setting component and Connector Stream setting components in case you have also made changes on the symbol naming in the MT4/MT5 System.

We filter out with the Provider Setting component for the requested liquidity provider and symbol to make a change (Match) to match how it should be set accordingly with the contract name provided by the Liquidity Provider.

Note: This action will ensure the subscription between XCore with the Liquidity Provider on the new contract.

We filter out with the Connector Stream Setting component for the Connector/Connector Stream/Symbol to make a change (Match) to match how it should accordingly to the naming on the MT4/MT5 Systems.

Note: This action will ensure subscription between XCore and MT4/MT5 System on the new contract.

Note: It is advisable always to check the subscription of the symbol was successful as it might require either Feeder Restart on MT4/MT5 side or Provider refresh on the XCore side.

Adding to the above will consider the situation of having 1 week prior to ending the current contact (WTI.APR) on the symbol (WTI.XX ) that was enabled before to enable the future contract (WTI.MAY) on the symbol (WTI.YY) that way both contracts will be active at the same time for a period of one week prior to the current contract ends fully.

By creating a second automation rule for the symbol WTI.YY

we are setting the time session when the configuration to the specific symbol should be active, which is 1 week prior to the current contract to end on the symbol WTI.XX.

The Source Field step again is left empty as the trigger for expiry product configuration is the Time Session when it should be active in the XCore.

Finally, in the Target Field step we configure the configuration that should apply on the Provider Setting and Connector Stream setting component for the symbol WTI.YY to be configured with the new contract of WTI.MAY accordingly.