PowerShell Automation

What is the Hopp PowerShell Module?

Hopp delivers a PowerShell module that can be used to automate the jobs that are normally submitted manually from the Portal Operations user interface.

The Hopp PowerShell module is an automation component within the Hopp data migration platform. It allows users to interact programmatically with Hopp’s migration environment, particularly the Portal and its underlying data structures. This module is designed to streamline repetitive tasks and enable advanced automation scenarios for complex migration projects.

---

By far - and indeed for many years - the normal use-case has been that one or more team users (operators) access the Portal Operations and from there submit migration jobs by manually identifying Business Objects, Views, Tables, Valuesets etc and submitting job to load, export, import and so on.

While this will certainly always be the case, there are some essential benefits brought to the table by the PowerShell Automation module:

Orchestration	3rd party orchestration software like Octopus Deploy, Control-M, Automic, Tivoli and others can use the Automation module to submit the migration jobs as part of a larger flow that includes both predecessor and successor steps in the end-to-end migration project.
Interactive	In the everyday development process, developers can use PowerShell and the Automation module to script jobs together in flows that can execute unattended - avoiding the need to monitor the job list to launch jobs in the flow as predecessor jobs complete

The Hopp Automation module consists of a series of PowerShell cmdlets to list items like Business Objects, Valuesets, Views Tables etc. Other cmdlets create parameterized jobs that are ready to be submitted. Parameterized jobs can then be submitted, and finally, a cmdlet can wait for submitted jobs to finish.

Especially of interest for the interactive use-case, the user can create a schedule to combine sets of ready-to-submit, parameterized jobs. A schedule can then be submitted as one unit and if the schedule terminates due to a faulted/cancelled job it can be restarted to resume execution from the point of failure.

Core Functionality

The module is a set of cmdlets grouped by task. Every cmdlet supports Get-Help for its parameters and examples.

Connecting:

• Connect-Hp signs in to the Portal and connects the session to a track. You can sign in interactively through a browser, or supply a ClientId and ClientSecret for an unattended server-to-server sign in from an orchestration tool. Once connected, the other cmdlets act on that track.
• Disconnect-Hp ends the session.

Listing migration content:

• Get-HpEntityList, Get-HpValuesetList, Get-HpSourceTableList and Get-HpSourceViewList retrieve the Business Objects, Valuesets, tables and views defined for the track.

Building jobs:

• The New-Hp...Job cmdlets and New-HpBatch create parameterized jobs that are ready to submit. They cover load, export, import, setup, unload, publish and reset operations.

Scheduling:

• New-HpExportSchedule and New-HpImportSchedule combine ready-to-submit jobs into a schedule. A schedule runs as one unit, and if it stops because a job faults or is cancelled it can be restarted to resume from the point of failure.

Submitting and monitoring:

• Submit-HpJob and Submit-HpSchedule submit the prepared work.
• Wait-HpJob and Wait-HpSingleJob wait for submitted work to finish, so a script can run a flow unattended.

Running tracks:

• Start-HpTrack, Stop-HpTrack and Get-HpIsTrackRunning start, stop and check the run state of a track.

Parameters and baselines:

• Get-HpParameterValue, Set-HpParameterValue, Get-HpExtensionParameterValue and Set-HpExtensionParameterValue read and set parameter values.
• Set-HpBaselineValuesets, Set-HpBaselineViews and Set-HpBaselineData set baseline data for the track.

Event data:

• Get-HpEventList retrieves a list of migration events from the Portal.
• Get-HpEventItemsDownload downloads detailed event data, including placeholders and values, into Excel or ZIP format for analysis. This supports installations where the Portal user interface is not fully utilized, so stakeholders can access detailed migration insights programmatically.

---

Deploying engines

The module can build and deploy migration engines to the Hopp Runtime, so engine deployment can run as a step in an automated pipeline alongside the migration jobs.

Two cmdlets cover this:

• Deploy-HpEngine deploys an engine from its project folder. By default it builds the engine project first, then deploys the result and returns the revision ID of the newly deployed revision. To deploy an output that is already built, supply the BuildFolder parameter to skip the build (for instance when the build output must be scanned before deployment). An optional Label identifies the revision.
• Set-HpTrackEngineRevision activates an engine revision on a track. Set the Engine to Source or Target. If TrackID is omitted, the track from Connect-Hp is used. If RevisionID is omitted, the newest deployed revision is activated.

A typical unattended deployment connects, deploys the engine, and activates the new revision on the track:

Connect-Hp -portalUrl "https://portal.url" -trackID "12345678-1234-1234-1234-123456789012" -clientId "(client id)" -clientSecret "(client secret)"

$revisionId = Deploy-HpEngine "(path to engine project folder)"

Set-HpTrackEngineRevision -Engine Source -RevisionID $revisionId

note

The folder passed to Deploy-HpEngine must contain the engine's MigFx.manifest and its .csproj file next to the build output. When the engine is built in a separate pipeline step, make sure these files are copied into that folder. When the cmdlet builds the engine itself (no BuildFolder), the .NET SDK build tools must be available on the machine that runs the deployment.

---

Why Use It?

• Efficiency: Reduces manual effort by automating jobs, engine deployment and reporting.

• Flexibility: Supports custom scripts for advanced migration scenarios.

• Transparency: Provides detailed event-level data for auditing and troubleshooting.