Skip to end of banner
Go to start of banner

Updating a Snaplex

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 88 Next »

In this Page

This dialog is available only to Org Admins when you click on a Snaplex within SnapLogic Manager or create a new Snaplex within Manager

The options available vary based on the type of Snaplex selected.


Support for Notifications through Slack

SnapLogic supports the Slack messaging app within the SnapLogic platform communications, enabling you as an Org admin to add Slack channels and recipients for your SnapLogic communications. For details on adding Slack communications to your Org, see SnapLogic Notifications through Slack.

Settings

The properties in this tab relate to the Snaplex.

Snaplex TypeIndicates if it is a standard Snaplex.
Name

The name of your Snaplex. Rename your Snaplex to provide a better description of the type or location. The name must not exceed 100 characters.

Renaming Snaplex Instances

If you rename a Snaplex, then you must perform the following actions:

  • Do a rolling restart on all the nodes in the Snaplex.
  • Update any Pipe Execute Snaps that reference the old Snaplex name with the new name.
LocationIndicates whether the Snaplex is in the cloud or on the ground.
Environment

Enter the value used to configure the Snaplex nodes. Alphanumeric characters and the following special characters are allowed:  - +

Example: Dev-10

Default value: No default value.

Snaplex nodes are typically configured using a slpropz configuration file, located in the $SL_ROOT/etc folder. 

If you use the slpropz file as your Snaplex configuration, then:

  • After a Snaplex node is started with the slpropz configuration, subsequent configuration updates are applied automatically.
  • Changing the Snaplex properties in Manager causes each Snaplex node to download the updated slpropz and does a rolling restart with no downtime on Snaplex instances with more than one node.
  • Some configuration changes, such as an update to the logging properties does not require a restart and are applied immediately.

Older Installations

If you have an older Snaplex installation and its configuration is defined in the global.properties file, then the Environment value must match the jcc.environment value In the JCC global.properties file. To migrate your Snaplex configuration to the slpropz mechanism, see Migrating Older Snaplex Nodes.

You should always configure your Snaplex instances using the slpropz file because you do not have to edit the slpropz files manually and changes to the Snaplex done through Manager are applied automatically to all nodes in that Snaplex, making configuration issues, which may prevent the Snaplex from starting, automatically reverted.

Version

The version of the Snaplex.

Update the version of your Snaplex by setting the Version in Manager. This manual update initiates a rolling restart of the nodes in the Snaplex. Each node is put offline with no new pipelines being sent to the node. The node waits a maximum of 15 minutes for currently running pipelines to finish and then restart itself with the new version of the Snaplex binaries. This process is repeated for each node. The Dashboard shows the updated nodes to be running with the new version.

Consider the following three designations when selecting the Snaplex version:

  • Recommended. Indicates that this distribution is the version you should use.
  • Restricted Distribution. Indicates that this version has a configuration intended for specific customers only.
  • Deprecated. Indicates that this version is being phased out and should not be selected.

Update Notifications

When you choose not to update your Snaplex manually and wait for the Automatic Update instead, you receive notifications until the Snaplex upgrade occurs. You can configure  your Snaplex instances within an Org to update automatically in Manager when a new version is available.

Minimum node per Snaplex

This option makes sure that the application master keeps a certain number of nodes alive even when there is no activity in the Snaplex (useful for Pipeline validation through Designer).

Minimum number is 1.

Email address for notifications

Enter the email addresses for notification if one of the Snaplex nodes does not respond for fifteen minutes.

Slack Channel for notifications

Enter the Slack channels, separated by commas, for notification if one of the Snaplex nodes does not respond for fifteen minutes.

Example: dev

Default value: None

Slack Channel for notifications

Enter the Slack recipients, separated by commas, for notification if one of the Snaplex nodes does not respond for fifteen minutes.

Example: testuser

Default value: None

Load balancerThe URL for the load balancer for Triggered Task  execution requests.

Ultra load balancer

The URL for the FeedMaster load balancer for Ultra Pipeline execution requests.

This is available only to those Orgs subscribed to Ultra Pipeline Tasks.

Snap Catalog Updates

When developing Pipelines in SnapLogic Designer, the version of the Snaps that you use depends on the current Snap Catalog for the Org.

  • If all the Snaplex instances in the Org are running the current platform version, then the Catalog uses the new version of Snaps.
  • If even one node in any Snaplex is running the older platform version, which is supported for five weeks from the date of the quarterly platform update, then the Snap Catalog shows the older version of Snaps. In this case, the Snap Catalog uses the older versions of the Snaps, as shown under the Old label in the View distribution dropdown list. are used. To check which version of the Snaps you are using to develop your Pipelines, see the Class FQID in the Snap Setting popup when opening the Pipeline for configuration.
  • If the Snap Catalog uses the older version of Snaps, the UI displays several indicators.

Indicators for Deprecated Snaplex

Between the release of the SnapLogic GA release and the Automatic Update, the UI alerts you if any Snaplex instances are outdated with the following indicators:

  • When you log in, SnapLogic Designer displays a warning message if a Snaplex is an older version than the latest release.

  • In Designer, Snaplex drop-down menu displays deprecated Snaplex in italics, shaded with a gray background.  When your cursor hovers over a deprecated Snaplex, the following message appears: Snaplex nodes running deprecated version.
  • In Dashboard, the tiles for deprecated Snaplex display the Snaplex name in italics, shaded with gray. When your cursor hovers over a deprecated Snaplex, the following message appears: <Snaplex_name> deprecated version.
     

  • In Manager, when you click the Snaplex, the Update Snaplex dialog appears. It includes a list of available versions, in which each version has one of the following three designations: 
    • Recommended. Indicates that this distribution is the version you should use.
    • Restricted Distribution. Indicates that this version has a configuration intended for specific customers only.
    • Deprecated. Indicates that this version is being phased out and should not be selected.


Updating a Snaplex requires an Org admin to change the version of the Snaplex settings in Manager to the current recommended version. This version update initiates a rolling upgrade for the nodes in the Snaplex to the new version. The indicators no longer display once you upgrade to the latest version of SnapLogic or after the Automatic Update.

Logging

The properties in this tab control how the nodes write log messages to the files in the /opt/Snaplogic/run/log directory. These log files provide the backing for the Pipeline logs viewable through the SnapLogic Dashboard. For more information on configuring Snaplex logs, see Configuration Options.

Logging updates happen with the next heartbeat check. No restart is required.


Level

The logging level that log messages must meet to be captured in the main log file. 

Select one of the following options:

  • Trace. Captures events at the most granular level, which is useful for deep analysis by developers.
  • Debug. Captures fine grained events and is typically used by Technical Support.
  • Info. Captures informational events that highlight the progress of the application.
  • Warning. Captures unexpected situations that might require attention.
  • Error. Captures error events that might still allow the application to continue running, but requires monitoring.

Recommended Level

We recommend you use either Debug or Info logging levels to facilitate troubleshooting.

Log file sizeThe maximum log file size, given as a number with a unit. For example, 50 MB for 50 megabytes.
Main backup countThe number of backup log files to keep for the main log (jcc.json).
Error backup countThe number of backup log files to keep for the error log (jcc_error.json).
Access backup countThe number of backup log files to keep for the access log (jcc_access.json).

Node Properties

This tab is used to configure properties for individual nodes. The first set of properties (Max slotsReserved slots, and Max memory) affect how pipeline executions are assigned to nodes in the Snaplex by the control plane. For example, if all of the slots on a node have been used for executing other pipelines, any new executions will be sent to other nodes in the Snaplex or the control plane will try to leave the execution in a Queued state until resources become available.

The remaining properties are used to configure the SnapLogic software running on the nodes in a Groundplex. The Groundplex nodes must have been setup to use an .slpropz configuration file before changes to these properties will take effect. If you make changes that affect the software configuration, but there are nodes in the Snaplex that are not setup to use a .slpropz configuration file, a warning dialog will appear with a listing of the unmanaged nodes. See the Downloads section below for more information on setting up a node to use this configuration mechanism.

Updates to Node Properties may require a restart of the Snaplex.


Maximum slots

The maximum number of slots available on each node in a Snaplex. Each Snap in a Pipeline will consume a slot, so Pipelines will only be executed on nodes where the number of slots currently in use is below this threshold. Otherwise, they will fail or be placed in the Queued state, depending on how they were executed. The number of slots-in-use corresponds to the number of active threads on a node, which can be viewed on the Monitoring Snaplex Health dashboard.

A restart is not required with a change to this setting, which can be set to a user-specified value.

Default value: 4000

Reserved slots %

The percentage of slots to reserve on a node for pipelines executed through the Designer tab. A restart is not required with a change to this setting.

Default value: 15

Pipelines executed using Tasks or the ForEach Snap will not have access to these slots.

Maximum memory %

The threshold at which no more pipelines will be assigned to a node.

A restart is not required with a change to this setting.

Default value: 85

Heap max size

Groundplex only. The maximum JVM heap size.

Default value: auto (meaning that SnapLogic will automatically set the max heap size based on the available machine memory).

HTTP interface

Groundplex only. Choose where the Snaplex node will accept HTTP network connections from. Options include:

  • Localhost only (127.0.0.1)
  • Any interface (0.0.0.0)
HTTP port

Groundplex only. The HTTP port the Snaplex node will listen on for connections.

Default Values: 8090 for a JCC node and 8091 for a FeedMaster.

HTTPS port

Groundplex only. The HTTPS port the Snaplex node will listen on for connections. 

Default Values: 8081 for a JCC node and 8084 for a FeedMaster.

Restart Max Wait Time

The maximum wait time before restarting a node. Enter the maximum wait time before restarting a node or click Forever for an infinite wait time.

Default: 15 minutes

Recommended. No greater than 60 minutes.

We recommend that you avoid setting the Restart Max Wait Time for too long because Snaplex nodes on an older version will stop accepting new Pipeline execution requests after the mandatory upgrade. This scenario can cause the nodes to wait for running Pipelines to complete and new Pipeline executions to not start as the older Snaplex version is no longer supported. The automatic Snaplex update has a 60-minute window during which the older version is supported. 

Snaplex node types: 
Hostname/Server type pairs

Groundplex only. Specify the type of service a Snaplex node should provide.

Applicable in Ultra-enabled environments.

Global properties: 
Key/Value pairs

Groundplex only. Internal configuration options. Do not edit these values without contacting SnapLogic Customer Support.



If you receive the following error: "reach the innerElementCountThreshold:50000", perform one of the following tasks:

  • Configure the Global Properties of the Groundplex in the global.properties file ("/opt/snaplogic/etc/global.properties" in Linux; "c:\opt\snaplogic\etc\global.properties" in Windows) to increase the threshold value:
    jcc.jvm_options = -Dorg.apache.cxf.stax.maxChildElements=<value>
    where 'value' is 1000000 or higher. OR
  • Add the same line as a global property in the node.

These properties are available only in a Groundplex.


Node Proxies

This tab controls how the nodes can communicate with an HTTP/HTTPS proxy server to communicate with the outside world. The Groundplex nodes must have been setup to use an .slpropz configuration file before changes to these properties will take effect. If you make changes that affect the software configuration, but there are nodes in the Snaplex that are not setup to use a .slpropz configuration file, a warning dialog will appear with a listing of the unmanaged nodes. See the Downloads section below for more information on setting up a node to use this configuration mechanism.

Updates to the Node Proxies will trigger a rolling restart of the Snaplex. A confirmation dialog will warn you if that is the case.


HTTP proxy  

Hostname and Port

HTTP proxy configuration

Non-proxy hosts: Host pattern

The hostnames or IP addresses that should be contacted directly instead of through the proxy. Patterns may start or end with a * for wildcards.
HTTPS proxy 

Hostname and Port

HTTPS proxy configuration

Non-proxy hosts: Host pattern

The hostnames or IP addresses that should be contacted directly instead of through the proxy. Patterns may start or end with a * for wildcards.

Setting up a new Groundplex Node

To setup a new Groundplex node,

  1. Download and install the appropriate package for your operating system.

    The Downloads tab is not visible until after a Snaplex is created. You must be an Org admin to access the Download links.

  2. After the software has been installed, download the following configuration file and place it in the /opt/snaplogic/etc directory and make sure the file name ends with .slpropz. The download link is valid for one hour. 

  3. To migrate existing Groundplex nodes to use the .slpropz configuration file, make sure the values in the Node Properties and Node Proxies match what you have configured in your global.properties file.

  4. Download the. slpropz configuration file, place it in the /opt/snaplogic/etc directory and restart the JCC service. 

If the Groundplex fails to restart after a new configuration is installed, it reverts back to the last working configuration.

Best Practices

  • When upgrading a Windows Groundplex to use the slpropz configuration file, the Monitor process would need to be updated by running jcc.bat update_service. The max heap space for the JCC process can be set incorrectly if the Monitor process is not updated.
  • If you are unable to create an SLDB file using international language characters (such as æ, Æ, Ø) in the file name, update the jcc.use_lease_urls property in the Snaplex's Global Properties to False. This workaround works for all UTF-8 characters, and hence supports all global languages.
  • By default, if the first run of an Ultra Task fails, SnapLogic attempts to run it for a total of five times. However, you can configure the number of times you want Ultra Tasks from a specific Snaplex to run by configuring the maximum number of allowed retries for an Ultra Task. To do so, modify the following parameter in Global Properties in Snaplex Update: ultra.max_redelivery_count to indicate the number of times you want a failed Ultra Task to run.

  • We recommend that for your critical workloads on the production environment, you use a minimum of two worker nodes (and two FeedMaster nodes for Ultra) to avoid service disruption during Snaplex upgrades.

Migrating older Snaplex nodes 

If you have a Snaplex  running with a global.properties file in the $SL_ROOT/etc folder, you should consider migrating the Snaplex to use the slpropz mechanism for the configuration. Running with global.properties file requires that for any configuration change you must manually update the global.properties file, copy the updated configuration to all the nodes, and then restart all the nodes.

We recommended  users migrate to the new slpropz mechanism for defining configuration files.

To migrate the Snaplex configuration to the slpropz mechanism:

  1. Update the Snaplex properties in Manager by adding custom configurations, which remain in the global.properties into the Snaplex properties.

    If you do not complete this step, then the configuration changes applied to the nodes are not available when running with slpropz.

  2. Navigate to the Manager > Update Snaplex > Downloads tab, and download slpropz file  into the $SL_ROOT/etc folder.

  3. Backup the global.properties and keys.properties files, then remove them from the $SL_ROOT/etc folder.

  4. Restart the JCC process on all the nodes through the Public API. Alternatively, as an Org admin you can restart the JCC node through the Dashboard by clicking  on the target node and selecting Node Restart.

The Snaplex nodes should run with the new slpropz mechanism, allowing for remote configuration updates.

  • No labels