nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to chose OD cfg automatically while deploying from any workarea

vikasp

Hello friends,

I am having requirement where i have to integrate 500 apllication to the TeamSite.each application will have its own WORKAREA.
I want to deploy each application to the appropriate UAT and LIVE server using workflow and OpenDeploy.

My workflow will be having following task
1.Author select the files from workarea and submit it
2.selected file will be deploy to the appropriate UAT servers
3.Reviewer will approve the task
4.selected files will be deploy to appropriate LIVE servers

I am using default deployment(wft_opendeploy.ipl) script.
There will be 2 seperate deployment cfg file(1 for UAT and 1 for LIVE) for each application.

Now requirement is that client dont wana select deployment cfg at time of workflow initiation.Workflow should take appropriate UAT and LIVE server cfg file automatically depending upon the WORKAREA value from where he submitting the file.

Please let me know is this possible? and if yes any pointers will be helpful.

Environment:TS 671SP1 Workflow modeler 1001 on solaris 10

Thanks in advance

Find more posts tagged with

Comments

nipper

Stuff like this is done all the time. However seldom with the wft_deploy.ipl script. This requires a custom deployment script, which you need to write. I hope you know Perl well enough, through the deploy.ipl you are using away and start coding.

new_report_26.rptdesign

vpatel

There are quite a few ways you can do this. One of the many ways to do this could be to simply figure out which WA is deploying the file and based on that execute OD deployment with different OD configuration file. If you are using the OOTB wft_opendeploy.ipl, you may have to customize that or you may be better off with writing your own custom perl script or Java code.

vikasp

Stuff like this is done all the time. However seldom with the wft_deploy.ipl script. This requires a custom deployment script, which you need to write. I hope you know Perl well enough, through the deploy.ipl you are using away and start coding.

Thanks for your reply
I am not great expert in perl.Can you please through some detail steps which i have to do follow.

vikasp

There are quite a few ways you can do this. One of the many ways to do this could be to simply figure out which WA is deploying the file and based on that execute OD deployment with different OD configuration file. If you are using the OOTB wft_opendeploy.ipl, you may have to customize that or you may be better off with writing your own custom perl script or Java code.

Hi vpatel,
I have to deploy from diffrent 500 workareas.there will b only one generic workflow.depending upon the value of WORKAREA i have to chose appropriate UAT and LIVE server deployment (OD cfg file which will conatin the deployName)

vpatel

Hi vpatel,
I have to deploy from diffrent 500 workareas.there will b only one generic workflow.depending upon the value of WORKAREA i have to chose appropriate UAT and LIVE server deployment (OD cfg file which will conatin the deployName)

That's fine you can 1 or 500 -- and you can create your code appropriately. You'll probably need some consistentency or some look up mechanism for your code to deploy content from each workarea to its target environment.

Like Andy said, this sort of configuration / customization is very common.

Adam Stoller

Thanks for your reply
I am not great expert in perl.Can you please through some detail steps which i have to do follow.

This is called design and implementation. We are not responsible for designing, or implementing, your work. The basics are simple, and you've already stated them.

jagadesh

1. Create Properties DCR in your workarea to contain the all target details to specific WA. While running the workflow read the properties file to extract the target(DB, Application Server).
2. Create custom configuration module to read the DCR and hold the DCR values as key and value pair
3. Using those values intiate deployment with the diff deploy configuration or use the same deploy config with diff parameters(better one)

Note:
Workarea name and Properties DCR name should be same and case sensitive as well. It should be easier in your script to read the details

Sample Code for Custom module


        my $rootnode = TeamSite:CRnode->new($xml);
  my @properties_container= $rootnode->get_node_list(DCR_ELEMENT);
  my (@keyarray, @valuearray, %hash);

  ##Need to loop twice inorder to get both Key and values items from DCR, probably TeamSite:CRNodes limitation, Down to line better to use XML::XMLPath.
  #First iteration to get all the keys values in the array from DCR
  @keyarray = map { $_->value('key') } @properties_container;

  #Second iteration to get all the values value in the array from DCR     
  @valuearray = map { $_->value('value') } @properties_container;

  @hash{@keyarray} = @valuearray;

 return \%hash;

Migrateduser

Is it just me or does that solution seem a tad overly complicated for the problem?

Adam Stoller

Is it just me or does that solution seem a tad overly complicated for the problem?

I thought so too, but didn't feel like figuring out a simpler solution.

server.zip

jagadesh

Sometimes the solution will be complicated for the requirement and customer expectation to achieve generic solution

groups.zip

Adam Stoller

Sometimes the solution will be complicated for the requirement and customer expectation to achieve generic solution

I'm still trying to understand why you think this is necessary:

...
##Need to loop twice inorder to get both Key and values items from DCR, probably TeamSite:CRNodes limitation, Down to line better to use XML::XMLPath.
#First iteration to get all the keys values in the array from DCR
@keyarray = map { $_->value('key') } @properties_container;

#Second iteration to get all the values value in the array from DCR 
@valuearray = map { $_->value('value') } @properties_container;

@hash{@keyarray} = @valuearray;
...

Instead of something like this:

...
$hash{$_->value('key')} = $_->value('value') foreach @properties_container;
...

...
my $hash = map { $_->value('key') => $_->value('value') } @properties_container;
...

Either would have the same end result with less processing and less space wasted for unnecessary variables (you could probably even get rid of @properties_container).

Then of course there's the question of whether you really want to maintain this in a DCR or just use a basic XML file for managing the mapping of branches to deployment specifications.

Whether or not you can just use simple substitutions in a generic deployment configuration file or need to use distinct deployment configuration files depends on whether all the deployments are identical except with respect to the target node(s). You might be able to parameterize other differences too and include such information in your mapping file, but if you have to start dealing with different filters and other options (permissionRules, transferRules, etc.) being different - you're probably better off with distinct config files and just mapping the branch to the config instead of to a set of command-line parameters to be passed to a generic config -- all of this is, of course, subject to the actual needs of the implementation - which we don't have, so we're just making guesses.

Hopefully vikasp has sufficient information now to make an informed decision about how to implement something for the customer.

scgs13_account_mgr_summary v0.rptdesign

vikasp

I'm still trying to understand why you think this is necessary:
...
##Need to loop twice inorder to get both Key and values items from DCR, probably TeamSite:CRNodes limitation, Down to line better to use XML::XMLPath.
#First iteration to get all the keys values in the array from DCR
@keyarray = map { $_->value('key') } @properties_container;

#Second iteration to get all the values value in the array from DCR 
@valuearray = map { $_->value('value') } @properties_container;

@hash{@keyarray} = @valuearray;
...
Instead of something like this:
...
$hash{$_->value('key')} = $_->value('value') foreach @properties_container;
...
Or
...
my $hash = map { $_->value('key') => $_->value('value') } @properties_container;
...
Either would have the same end result with less processing and less space wasted for unnecessary variables (you could probably even get rid of @properties_container).

Then of course there's the question of whether you really want to maintain this in a DCR or just use a basic XML file for managing the mapping of branches to deployment specifications.

Whether or not you can just use simple substitutions in a generic deployment configuration file or need to use distinct deployment configuration files depends on whether all the deployments are identical except with respect to the target node(s). You might be able to parameterize other differences too and include such information in your mapping file, but if you have to start dealing with different filters and other options (permissionRules, transferRules, etc.) being different - you're probably better off with distinct config files and just mapping the branch to the config instead of to a set of command-line parameters to be passed to a generic config -- all of this is, of course, subject to the actual needs of the implementation - which we don't have, so we're just making guesses.

Hopefully vikasp has sufficient information now to make an informed decision about how to implement something for the customer.

Thanks ghoti,
I am maintaining all the deployment related config files in the master DCR.

jagadesh

Just i given samples of basic. It does not mean that you should replace the same thing. As a developer you should modify the sample to use the logic for your requirement.