Migration Patterns

[dmiller]

The following patterns migrate assets from one project to another in the same org. These patterns make use of the SnapLogic Metadata Snaps.

Source: Existing accounts, files, and pipelines within SnapLogic
Target: A second project within SnapLogic
Snaps used: SnapLogic Metadata Snaps, Mapper,

Requirements

• You must have access to both projects.
• You will need to define the following pipeline parameters:
  • source_path, in the form of /orgname/projectspace/project
  • target_path, in the form of /orgname/projectspace/project

Migrate Accounts

• The SnapLogic List Snap gathers the list of accounts in the specified source_path parameter.
• The SnapLogic Read Snap reads the incoming $path for the accounts.
• The Mapper Snap maps the target path.
• The SnapLogic Create Snap writes the accounts to the target location.

Migrate Files

• The SnapLogic List Snap gathers the list of files in the specified source_path parameter.
• The Mapper Snap maps the source path to a $source_path field for use in the Read Snap.
• The SnapLogic Read Snap reads the incoming $path for the files.
• The SnapLogic Create Snap writes the files to the target location.

Migrate Pipelines

• The SnapLogic List Snap gathers the list of pipelines in the specified source_path parameter.
• The SnapLogic Read Snap reads the incoming $path for the pipelines.
• The Mapper Snap maps the target path.
• The SnapLogic Create Snap writes the pipelines to the target location.

Pipeline Downloads

• Migrate Accounts.slp (5.7 KB)
• Migrate Files.slp (6.0 KB)
• Migrate Pipelines.slp (5.7 KB)

[jcampion]

The Migrate Files pipeline did not work for me. Apparently the File Writer currently cannot write to orgs other than the one it’s in.

[Szymon]

Migrate Files definitely does not work.
I am not sure if this is another BUG, but the File Writer result says “overwritten”, no error whatsoever.
I am tired of creating tickets 🤢
Everything you touch on snaplogic seems to be buggy 😭

{
“filename”: “sldb:///myotherorg/myspace/myproject/file.name”,
“result”: “overwritten”
}

[dmiller]

@Szymon

The following patterns migrate assets from one project to another in the same org.

Are you trying to write to a different org or are you seeing this error when trying to write to a different project in the same org?

[Szymon]

Ahh! Now I see. Apoligies for not reading correctly.
Clever naming, really, that try to cover missing functionalities, well done!
I am not sure if snaplogic is aware of it, but since 1970’s, there was some progress in IT.
Requirements, like migrating/deploying/etc. single objects/assets/etc.(and not whole projects with all the assets) from one stage to another (e.g. dev → uat, uat → prod, etc.) are already standard in integration platforms nowadays.
But I recon snaplogic is first at stage of copying objects only in within one stage. AND it requires custom development, really advanced!

So, this seems to confirm it as a bug, that even though file writer says “overwritten”, file is not being written, therefore it is not there.
{
“filename”: “sldb:///myotherorg/myspace/myproject/file.name”,
“result”: “overwritten”
}
No furhter questions.
kind regards!

[koryknick]

@Szymon - File Writer will not write directly to another org. The status of “Overwritten” is not a bug. If you use Manager to check the project where the pipeline has been executed, you will see a Directory structure with the full path of the file you had written.

Keep in mind that the SLDB protocol refers to the current org SLDB, so it is interpreting that path you give it as a local path in your current org. This is different from the SnapLogic Metadata snaps that are intended to work with metadata and cross-org functionality.