Skip to content

v7.3.0 - manage journeys
Compare
Choose a tag to compare
@JoernBerkefeld JoernBerkefeld released this 28 Aug 23:23
· 316 commits to main since this release
v7.3.0
5e97ce7

Features

Bugfixes

Chores

Full Changelog: v7.2.0...v7.3.0

Details

Standard Commands

delete

Command: mcdev delete <business unit> [type] [external key] [--metadata]

Alias: mcdev del

Deletes the given metadata from your server. This needs to be run with care as any data stored in the deleted meta-data will be lost.

Currently supported types: Metadata Type Support

Example:

mcdev delete MyProject/_ParentBU_ dataExtension MyUserTable

You can also delete multiple keys at once, even across types:

mcdev delete MyProject/_ParentBU_ -m dataExtension:MyUserTable -m query:myKey -m query:myKey2

mcdev delete MyProject/_ParentBU_ dataExtensionField MyUserTable.MyFieldName

Journeys are somewhat special because they are the only metadata type in SFMC that has versions stored in the platform itself. Therefore, when deleting a journey, you need to specify what version you want to delete - or if you want to delete the journey with all its versions. You achieve that by appending "/3" for deleting version 3 or "/*" for deleting all versions.
You can even provide the journey ID instead of the key. In the first example below, we are trying to delete version 4 of ID "5cfb1bcb-9cb7-42c9-81de-033943bbc18c".

mcdev del MyProject/_ParentBU_  journey id:%235cfb1bcb-9cb7-42c9-81de-033943bbc18c/4
mcdev del MyProject/_ParentBU_ journey id:5cfb1bcb-9cb7-42c9-81de-033943bbc18c/4
mcdev del MyProject/_ParentBU_ -m journey:id:5cfb1bcb-9cb7-42c9-81de-033943bbc18c/4
mcdev del MyProject/_ParentBU_ -m journey:myJourneyKey/4

mcdev del MyProject/_ParentBU_ -m journey:myJourneyKey/*

Note for nerds: When copying the ID from the URL, you might notice it's prefixed with "%23". If you do copy that together with the Id, mcdev del will automatically filter it for you. It, therefore, works with or without the leading "%23".

pause

Command: mcdev pause <business unit> [type] [key] [--like] [--metadata]

Alias: mcdev p

This command lets you pause metadata of a given type and key.

Currently supported types:

Name CLI Argument Effect
Automation automation pauses scheduled automation
Journey journey pauses running journey

Example:

mcdev pause MyProject/DEV automation key1
mcdev pause MyProject/DEV journey key3
mcdev pause MyProject/DEV journey key3/4
mcdev pause MyProject/DEV journey key3/*
mcdev pause MyProject/DEV automation "key1,key2,key3"
mcdev pause MyProject/DEV -m automation:key1 -m automation:key2
mcdev pause MyProject/DEV -m automation:key1 automation:key2 journey:key3

For journeys you can choose to specify a specific version to pause by appending "/4" (to pause version 4) or all versions by appending "/*". If you do not append a version, mcdev will attempt to pause the latest version.

pause with --like operator:

mcdev pause MyProject/DEV automation --like.key "myprefix_%"
mcdev pause MyProject/DEV automation --like.key "myprefix_%" --like.r__folder_Path "Query/Testing%"

pause on all BUs:

This is a variation of pause command that allows you to pause specified items on all BUs. mcdev will look for the items of specified types and keys on all BUs and pause them.

Example:

mcdev pause MyProject/* automation key1
mcdev pause MyProject/* automation "key1,key2,key3"

stop

Command: mcdev stop <business unit> [type] [key] [--like] [--metadata]

Alias: -

This command lets you stop metadata of a given type and key.

Currently supported types:

Name CLI Argument Effect
Journey journey stops running journey

Example:

mcdev stop MyProject/DEV journey key3
mcdev stop MyProject/DEV journey "key1,key2,key3"
mcdev stop MyProject/DEV -m journey:key1 journey:key2

For journeys you can choose to specify a specific version to stop by appending "/4" (to stop version 4). If you do not append a version, mcdev will attempt to stop the latest version. Currently, you cannot stop all versions at once with a single command.

stop with --like operator:

mcdev stop MyProject/DEV journey --like.key "myprefix_%"
mcdev stop MyProject/DEV journey --like.key "myprefix_%" --like.r__folder_Path "my Journeys/Testing%"

stop on all BUs:

This is a variation of stop command that allows you to stop specified items on all BUs. mcdev will look for the items of specified types and keys on all BUs and stop hem.

Example:

mcdev stop MyProject/* journey key1
mcdev stop MyProject/* journey "key1,key2,key3"
mcdev stop MyProject/* -m journey:key1 journey:key2 journey:key3

Templating Commands

build

Command: mcdev build <--buFrom> <--marketFrom> <--buTo> <--marketTo> <--metadata> [--bulk] [--dependencies] [--retrieve]

This combines the power of buildTemplate and buildDefinition in one command, making it easier if you continuously use both commands sequentially.

Example:

// before
mcdev bt MyProject/DEV --market pilotMarketDEV1 -m dataExtension:table1 -m dataExtension:table2 -m dataExtension:table3 -m query:sql1 -m query:sql2
mcdev bd MyProject/QA --market pilotMarketQA1 -m dataExtension:table1 -m dataExtension:table2 -m dataExtension:table3 -m query:sql1 -m query:sql2

// after
mcdev build --buFrom MyProject/DEV --buTo MyProject/QA --marketFrom pilotMarketDEV1 --marketTo pilotMarketQA1 -m dataExtension:name:table1 dataExtension:table2 dataExtension:table3 query:sql1 query:name:sql2

Note how you can also use names instead of keys to select metadata by prefixing the name with "name" (e.g query:name:sql2). That however, only works if the name exists only once. Otherwise, the system will show an error, providing the found keys for you to select.

And if you already have market lists set up and want to use buildDefinitionBulk instead all you need to do is append --bulk:

Example:

// before
mcdev bt MyProject/DEV --market pilotMarketDEV1 -m dataExtension:table1 -m dataExtension:table2 -m dataExtension:table3 -m query:sql1 -m query:sql2
mcdev bdb pilotMarketsQA -m dataExtension:table1 -m dataExtension:table2 -m dataExtension:table3 -m query:sql1 -m query:sql2

// after
mcdev build --buFrom MyProject/DEV --marketFrom pilotMarketDEV1 --marketTo pilotMarketsQA --bulk -m dataExtension:table1 -m dataExtension:table2 -m dataExtension:table3 -m query:sql1 -m query:sql2

Note how in this bulk-example the parameter --buTo MyProject/QA was omitted and that --marketTo pilotMarketsQA now holds the name of the market list that bdb needs to work.

build with --dependencies (and with --retrieve):

These two parameters are passed through to buildTemplate. Please see that commands documentation for details. The resulting list of types & keys of whatever buildTemplate will create are then handed over to buildDefinition(Bulk), making this a powerful solution.

build with multiple chained markets

If you have more complex scenarios that would otherwise require setting up lots of mostly cloned markets. Instead, you may define multiple markets that can combined to form one new set of variables that then get applied.

mcdev build --buFrom MyProject/DEV --marketFrom pilotMarketDEV1 addtionalMarketDEV --marketTo pilotMarketsQA addtionalMarketQA --bulk -m dataExtension:table1 -m dataExtension:table2 -m dataExtension:table3 -m query:sql1 -m query:sql2

This will take pilotMarketDEV1 and add whatever is defined in addtionalMarketDEV. If there is an overlap in defined attributes, whatever market is set second, overwrites what is set first in the command. You can chain as many markets as you want. The order of how the markets are defined in the config does not have an effect.

"markets": {
  "addtionalMarketDEV": {
    "c": 6,
    "d": 4,
    "e": 5,
  },
  "pilotMarketDEV1": {
    "a": 1,
    "b": 2,
    "c": 3,
  }
}

The resulting market would be

  {
    "a": 1,
    "b": 2,
    "c": 6,
    "d": 4,
    "e": 5,
  }

buildTemplate

Command: mcdev buildTemplate <business unit> [type] [key] [market] [--metadata] [--market] [--dependencies] [--retrieve]

Alias: mcdev bt

The bt command uses previously retrieved metadata on your local computer and uses your market configuration in .mcdevrc.json to replace strings with variables. The result is then stored in your template/ folder. Please note that files stored here will keep their original name, despite this possibly containing market-specific suffixes or similar. Also note, that contrary to the deploy & retrieve folders, you will not see credential- or Business Unit-sub-folders here.

This command is a prerequisite for the buildDefintion command. Alternatively, you can copy-paste retrieved metadata from your retrieve/ folder to your template/ folder and update it manually - or even create it from scratch.

Note: Before using this command, you need to configure your markets first! Check out our guide on Market Configuration to understand how to use templating and prepare your market config.

Currently supported types: Check out Metadata Type Support.

Example:

mcdev bt MyProject/DEV dataExtension MyUserTable pilotMarketDEV1
mcdev bt MyProject/DEV --market pilotMarketDEV1 -m dataExtension:MyUserTable dataExtension:name:MyUserTableName

This will result in MyUserTable.dataExtension-meta.json being created in your template/ directory. Note how you can also use names instead of keys to select metadata by prefixing the name with "name" (e.g query:name:sql2). That however, only works if the name exists only once. Otherwise, the system will show an error, providing the found keys for you to select.

buildTemplate with multiple chained markets
See build with multiple chained markets chapter above

[...]

buildDefinition

buildDefinition with multiple chained markets
See build with multiple chained markets chapter above

[...]

buildDefinitionBulk

buildDefinitionBulk with multiple chained markets
See build with multiple chained markets chapter above for what this good for. Due to how bdb works, you have to specify multiple chained markets in a marketList for this to work. Also, because the default logic already allows specifying arrays of markets, you have to specify an array of an array of strings.

Without chaining, the config would look like this and result in buildDefinition getting run twice seperately. Once for QA-DE market, and once for QA-GULF market:

"markets": {
    "QA-DE": {
        "a": 1,
        "c": 3
    },
    "QA-GULF": {
        "a": 2,
        "b": 2
    }
},
"marketList": {
    "Parent-shared": {
        "description": "used to deploy shared data extensions",
        "MySandbox/_ParentBU_": ["QA-DE", "QA-GULF"],
    }
}

With chaining, the config would look like the following and result in buildDefinition being run once for QA-DE market and QA-GULF market merged:

"markets": {
    "QA-DE": {
        "a": 1,
        "c": 3
    },
    "QA-GULF": {
        "a": 2,
        "b": 2
    }
},
"marketList": {
    "Parent-shared": {
        "description": "used to deploy shared data extensions",
        "MySandbox/_ParentBU_": [
			["QA-DE", "QA-GULF"]
		]
    }
}

The resulting market would have these variables:

{
        "a": 2,
        "c": 3,
        "b": 2
}

Contributors

JoernBerkefeld
Assets 2
Loading