What is the Axeda Compatibility Package? > ThingWorx Software Content Management (SCM) Extension
ThingWorx Software Content Management (SCM) Extension
Why SCM?
Suppose you need to update the software on 100 MRI machines. To accomplish this task without SCM, you would need to follow a process similar to the this:
1. Locate the desired set of 100 Things representing MRI Machines on your ThingWorx Platform.
2. Using the File Transfer Subsystem, for each MRI Machine, issue a FileTransferSubsystem.Copy() request to copy the set of files to each MRI Machine.
3. Using the ThingWorx Remote Access capabilities, for each MRI Machine, establish a VNC session to each target MRI Machine and execute the commands necessary to update the software.
4. Manually enter data in a log, indicating the version of software installed on each machine.
This process is manually intensive and error-prone. ThingWorx Software Content Management (SCM) provides a solution.
Software Content Management (SCM) allows for the creation of software content and distribution of that software content to a set of target assets in a controlled manner. SCM automates the manually-intensive and error prone process of distributing and installing new software to your assets.
SCM is comprised of the following high-level pieces:
Package—The software content to be delivered.
Deployment—A request to the ThingWorx Platform to deliver and (optionally) execute the software content described in a Package to a set of target Assets.
Assets—The edge devices receiving the software content defined in the Package and requested by a Deployment.
Using the above example where you wish to update the software on 100 MRI machines, using ThingWorx SCM, you can
1. Log in to ThingWorx Composer and navigate to the SCM utility.
2. Create a package that contains the details about the software to be transferred to the MRI machines.
3. Create a Deployment that targets the 100 MRI Machines (the Assets) with the Package that was just created.
4. Start the Deployment.
The Package is transferred to the 100 Assets, and the Assets are updated with the new software. The ThingWorx Platform automatically updates its records about the new version of software now installed on the MRI Machines.
A flexible SCM solution that works with many types of Assets including ThingWorx EMS/Lua-based assets, agents based on the various ThingWorx Edge SDKs, or Azure IoT assets is fundamental to the ThingWorx Platform.
Solution: ThingWorx SCM Extension
The ThingWorx Software Content Management (SCM) extension provides basic package creation and deployment tools. Two types of packages can be created:
Instruction-based packages for assets running Axeda eMessage Agents. With release 2.1.0, a new instruction for setting data items (properties) is provided with the SCM extension.
File-based (script) packages for assets running the ThingWorx Edge MicroServer (EMS) or applications written using the ThingWorx Edge C SDK or the ThingWorx Edge .NET SDK. These SDKs require an SCM Edge Extension to be configured in the application.
Releases and SCM Functionality
The following table lists the releases of the Axeda Compatibility Package (ACP) and summarizes the SCM functionality provided in the releases.
* 
If you want to use the SCM instruction, SetProperty, which is similar to the Axeda SetDataItem SCM instruction, you must upgrade to ACP v.2.1.0.
If you want to use the ThingWorx High Availability (HA) Clustering, you must upgrade the ACP to at least v.2.0.0, which supports the SCM instructions in an HA environment .
ACP Release
Functionality
1.2.3
An SCM deployment with an instruction to download a file failed for Axeda Agent Embedded.
With this release, it is possible to download a file successfully to Agent Embedded. However, it does not mean that the eMessage Connector fully supports Agent Embedded yet. Keep in mind the following limitations of Agent Embedded:
Agent Embedded does not handle compressed files.
Agent Embedded supports only Upload, Download, and agent Restart instructions.
Agent Embedded does not support the Execute instruction that can be added for a ThingWorx SCM instruction-based package.
1.2.2
Support for using SCM with ThingWorx Platform 8.5.0.
1.2.1
Removal of IDM agent support, including for SCM.
1.2.0
Support for SCM Upload instructions for eMessage agents.
1.1.0
SCM support for Axeda eMessage agents (Axeda Gateway and Axeda Connector) consisted of Download, Execute, and Restart instructions only.
For details about Upload instructions, refer to . For complete information about using the ThingWorx SCM Extension and its user interface for your Axeda Agent assets, refer to the ThingWorx Utilities Help Center at https://support.ptc.com/help/thingworx/utilities/r9/en/.
SCM Support for Download Instructions
As of release 1.2.0 of the Axeda Compatibility Package and release 1.1.0 of the ThingWorx SCM Extension, the Extension and the eMessage Connector support additional instructions for instruction-based packages. More specifically, in addition to the Download and Execute instructions, Upload and Restart instructions are supported.
The eMessage Agents must be configured to load their SoftwareManagement (eSM or xgSM) component on startup. The settings for the component let users specify the number of concurrent packages that the Agent should process. Recall that the eMessage Agents process file upload requests in the same way as they process SCM packages, no matter where the request originates.
Required Thing Shapes for Axeda Things
After starting an eMessage Agent, you must ensure that the following Thing Shapes have been assigned to the corresponding Things in ThingWorx Composer:
TW.RSM.SFW.ThingShape.UpdateableWithInstructions
PTC.Resource.Asset.SCMResourceThingShape
Visibility for ThingWorx Utilities
Visibility support for multiple organizations is available for non-asset entities (mashups, helper Things, and so on). The TW.UTL.UtilSetupHelper resource contains the AdjustUtilitiesVisibility service to help align visibility and permission for ThingWorx Utilities.
* 
To set visibility you must be an administrator or have the correct permissions.
Complete the following steps to set visibility:
1. In ThingWorx Composer, navigate to System ▶ Resources.
2. Click TW.UTL.UtilSetupHelper, and then click Services.
3. Click Test next to the AdjustUtilitiesVisibility service.
4. Enter the organization for which you want to execute the service, or you can use a colon to enter the unit as well. In the example below, running the service sets visibility for the core entities that are available to ThingWorx Utilities and some platform entities (subsystems, resources, and so on) for the AcmeOrganization and the AcmeUn5.
5. Click Execute Service.
Required Visibility/User Group Membership for SCM
The pre-defined User Group, ComposerUsers, allows administrators to restrict access to ThingWorx Composer to only the users (or other User Groups) that are members of this group. Note that many of the permissions that were moved out of the "Everyone" group into ComposerUsers are required for SCM. Add SCM users to the ComposerUsers group so that they have the required visibility and permissions to use SCM. In addition, make sure that your SCM users have permissions and visibility to the edge devices (Things) for which they will be creating and deploying packages.
* 
The SCM Extension adds the RSMAdmin group and RSMRemoteServices groups to ThingWorx user groups. Make sure that you add the non-admin users to the RSMRemoteServices group as well as to the ComposerUsers group. Members of this group cannot delete a package, unless they have created the package or have the Delete permission.
SCM Support for Upload Instructions (eMessage Connector ONLY)
The Data Shape, SCM.API.DataShape.Instruction.Upload, represents Upload instructions. This Data Shape has the following fields:
Parameter
Base Type
Description
Required?
Example
RepositoryName
STRING
File Repository on the ThingWorx Platform where the file is uploaded.
Yes
SystemRepository
DestinationPath
STRING
Where to store the uploaded file within the repository (file is placed in a Thing-specific directory under this path)
Yes
/
SourceFiles
INFOTABLE
An infotable containing one or more file names, describing what files should be uploaded
Yes
reference below
The SourceFiles parameter uses the GenericStringList Data Shape, which has one field, item, of base type STRING. Each item is a specification for a file, using a relative path name of the file(s) to be uploaded. Wild cards can be included (*, ?). For example, *.log uploads all files with the extension log from a Gateway agent on the file system of the asset. Since the Gateway path is already relative, you do not need to specify a full path here.
File Cleanup
For now, you need to either manually take one of the following actions or configure something else to clean up your SCM Upload repository automatically:
Add a Timer that when fired, deletes all uploaded files that are older than a certain age. The age should be configurable and should be limited to those files located in the designated repository for SCM uploads.
Remove uploaded files for Things that no longer exist (could be done on the Timer mentioned in the first point or on a future "Thing deleted" event subscription).
What Is Not Supported
Axeda users could pause and resume file transfers through the Asset dashboard for the device in the Axeda Console. This functionality is not supported in the ThingWorx Platform for SCM uploads or uploads through the Copy service of the File Transfer Subsystem.
On the Axeda Platform, it was possible to resume partial uploads by specifying the starting position in the upload instruction sent to the agent. This feature was supported only for files that were not compressed. Due to the nature of compressed uploads and the fact that uncompressed uploads are not currently supported, ThingWorx SCM removes uploads for delivery targets that retry or fail rather than trying to resume them.
Axeda Platform could be configured to either keep previous uploads of files with the same name uploaded by the same device or to remove the older files when new versions were uploaded. This ability to overwrite existing files is not supported. In the ThingWorx Platform, the uploaded files are in the compressed files until the upload repository is cleaned; ThingWorx does not do anything special to preserve versions of files.
Since overall checksums are validated, ThingWorx SCM does not support chunk checksums.
Absolute file specification paths are considered a security risk and, therefore, ThingWorx SCM supports only relative file specification paths.
Axeda Platform provided an option to delete after upload. Since you can do this using an Execute instruction after the Upload instruction in ThingWorx SCM, this Axeda-specific option is not supported.
Axeda Platform automatically extracted the file listing from a compressed archive to show the user the individual files. ThingWorx SCM does not provide this capability. Users need to go to the File Repository used for SCM uploads to view the compressed files and then download and extract them. To view files in this repository, users need permission to refer to the repository.
ThingWorx SCM sanitizes the TargetPath with the Thing name to remove illegal directory name characters. This process may cause duplicate directories. At this time, ThingWorx SCM does not guarantee that the path does not conflict with another Thing's path.
Was this helpful?