FME Server Workspace life cycle for the Enterprise

Developing and deploying a new FME Workspace in the Enterprise may involve several systems before the workspace goes live in a production environment. The workspace may first begin in a Development (DEV) environment and then be migrated to a Testing (TEST and/or QA) environment for checks or quality insurance. Passing all the tests and checks, it can then be promoted to the Enterprise Production (PROD) environment.

There are four methods available for publishing and migrating workspaces through the DEV/TEST/PROD environments, each with its own pros and cons:

• FME Desktop Publish Wizard
• FME Server Backup and Restore
• FME Server Projects
• FME Server REST API

Recommendations and Best Practices

FME Desktop Publish Wizard
Using FME Desktop to publish a workspace to FME Server is the recommended workflow. FME Desktop takes care of all the settings and registrations to the different FME Server web services (i.e., Data Streaming, Data Download, Job Submitter, and others).

Pros

• Easily register workspaces to any of the available web services.
• Configure workspaces to interact with the Notification Service.
• No custom or third-party applications are required.

Cons

• Automation is not possible. Requires manual migration to move from DEV to TEST to PROD.
• Inefficient when dealing with large numbers of workspaces and different systems.
• When publishing a new workspace a review of service registrations, security policies, and resources may be required.
• For more complicated workspace workflows that involve multiple workspaces (parent-child), notifications, and file resources, the admin must follow documented, repeatable steps that produce a consistent result.

Publishing using FME Server's Backup and Restore
FME Server provides backup and restore tools that allow you to migrate your existing FME Server configuration (workspaces, service registrations, resources, etc) from one environment to the next environment in the workspace life cycle; for example from a DEV to a QA environment. These tools are available on the FME Server Web User Interface and do not require FME Desktop.

Pros

• Easy migration of all workspaces in one step.
• Ensures all workspaces are migrated - no missing pieces. Configurations in the previous environment are maintained, including: service registrations, security policies, and resources.
• Can update existing workspaces to newer versions, if desired.
• Can insert new workspaces only, without overwriting existing workspaces, if desired.

Cons

• Cannot track details about changes (updates vs inserts) - no visibility of what was replaced or inserted.
• Cannot select a subset of workspaces to restore.
• Option to overwrite existing items is all-or-nothing. Cannot pick-and-choose.
• Considerations for different FME Server security modes must be considered when using Active Directory security. For example, you may develop a workspace in DEV where Active Directory is not used. After restoring to the PROD environment, security must be reviewed in the FME Server Web User Interface to ensure the appropriate users and roles have access as designed.

• Easy migration of workspaces and related objects
• Chunk workflows into smaller more manageable parts to migrate
• Wrap Projects up in two a master project
• Can update existing objects to newer versions
• Pause Notifications System during import
• Can review the history of Project Import and Export Activity

• May need to deal with multiple projects and could be challenging to manage

Publishing using the REST API

Pros

• Efficiency - Can create an automated, repeatable process for workspace migration.
• Desirable results for workspaces that use the FME Server Job Submitter service.
• Integration with external source control applications via webhooks.

Cons

• Cannot configure how workspace Readers and Writers interact with the Notification with different Services.
• Requires customizing or developing an application to interface with the FME Server REST API and the source location of workspaces. Developer resource likely required.
• All configurations in the previous environment are not automatically maintained. This requires reviewing service registrations, security policies, and resources when publishing a new workspace.