Wildcard characters for version name in requestApplicationProcess command of CL/I UCD

Thanks for information and status update.

That the usage of wildcard on versions during deployment has impact on its order.

The customer has given feedback too they set some internal oder in their current tool like copy packages first and then load packages during deploy which is managed in current tool and used during deployment.

And Thanks for the recommendation if it is needed that script could also be used to create versions in right oder instead of using wildcard.

On any further Idea I use your idea portal for creating new ones. Thanks.

To run an application process for two versions say B0001 and B0002, application process request JSON looks something as below.

{
    "application": "Application 1",
    "applicationProcess": "Deploy",
    "environment": "Environment 1",
    "versions": [
        {
            "version": "B0001",
            "component": "Component1"
        },
        {
            "version": "B0002",
            "component": "Component1"
        }
    ]
}

The order of versions in above JSON is the same order in which the versions are deployed while running an application process. B0001 version is deployed first followed by next version B0002 and so on.

As per this RFE customer would like pass a regular expression in version attribute as below.

{
    "application": "Application 1",
    "applicationProcess": "Deploy",
    "environment": "Environment 1",
    "versions": [
        {
            "version": "B000*",
            "component": "Component1"
        }
    ]
}

Drawback with having a Regular Expression/wildcards version name is we lose control over the order in which the versions are to be deployed.

For e.g., in this scenario, version B0002 might be deployed prior to version B0001. This will create problem for incremental versions deployment.

One workaround I could think of is to pull list of versions from component and write a script to generate applicationProcessRequest JSON with versions and order of deployment required and this will give an advantage of reviewing the order and request before running it on the server.

We are looking for feedback from customer on the order issue with wildcards/Regular Expressions in version.

Updated information as comment to idea.

���

Mit freundlichen Gr����en / Best Regards

Bharath Eluri

���

For more information.

The requestapplicationprocess CL/I command is allowing the multiple versions in json request but not the wildcard characters.

https://www.ibm.com/docs/en/urbancode-deploy/7.2.0?topic=commands-requestapplicationprocess

UDCLIENT zOS Unix Shell Command in a JCL:

//JOBXXX JOB CLASS=A,NOTIFY=SYSUID

//BUZTOOL EXEC PGM=BPXBATCH,REGION=0M

//STDOUT DD SYSOUT=*

//STDERR DD SYSOUT=*

//STDPARM DD *

SH $UDCLIENT/udclient requestApplicationProcess

$HOME/jsons/"Deploy.json"

Allowed Json file in for the requestApplicationProcess command.

{

"application": "Application 1",

"applicationProcess": "Deploy",

"environment": "Environment 1",

"versions": [

{

"version": "B0001",

"component": "Component1"

},

{

"version": "B0002",

"component": "Component1"

}

]

}

And not allowed wildcard for the component version name with in the Json file is.

{

"application": "Application 1",

"applicationProcess": "Deploy",

"environment": "Environment 1",

"versions": [

{

"version": "B00*",

"component": "Component1"

}

]

}

If this would be possible then it would be possible to deploy the versions B00* using scheduled JCL Job in an mainframe scheduler.

Something similar is possible in web ui of ucd by setting Versions with Name field as B00* during the request.

But this has to be set each time. So even in web ui it is't possible to schedule deploy of all versions B00* every day at specified time.

I would like to request you mainly first if the this CL/I command's request json file supports version parameter with wildcard like B00* to be able to use the command in a JCL.

Secondly if this would be possible in web ui to set in recurrent request one time instead of each time.