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; } } }

Migration to Data Deploy 6.0.2 <dbLoader> issue

Daniel_Cruz

Hi all,

We are migrating legacy OpenDeploy deployment configuration files from an Interwoven OD-DD version 5.6 to 6.0.2

In our 5.6 environment, deployment configurations are configured to use the DeployNRun feature to update DCR XML data for File and Database data synchronization: the workflow code calls an OD deployment configuration file responsible for deploying file assets. This file calls to a second deployment configuration file which calls the DataDeploy ddsync Perl script to sinchronize DCRs into DB.

We need to replicate the same behavior in the new version 6.0.2. The Interwoven documentation tells that this type of deployment must be carried out with a new XML tag <dbLoader>. This tag ensures synchronization between file content and DCRs into DB, and we are doing some tests to make all of our OD deployment configurations to include this tag.

To be precise, our problem can be described as follows:
- When DCR to be deployed doesn't exist in the database, the deployment is successfully completed.
- When the DCR data to be deployed previously exists in the database (we want to update DCR data), the deployment fails giving us a data integrity error (an INSERT during the deployment duplicates primary key data). We think that DataDeploy should manage this case to avoid such integrity error. The Interwoven documentation doesn't tell us how to solve this problem

Our work environment is described below:
- Migration Source: Interwoven OD-DD 5.6 system over Windows 2000 server. Database DB2 version 7.
- Migration Target: Interwoven OD-DD 6.0.2 system over Windows 2000 server. Database DB2 version 8.

We add an attachment with dbschema, OD deployment config file and the generated DD config file.

Any help would be appreciated. Thanks in advance.

Find more posts tagged with

Comments

Adam Stoller

If you used to use a DNR script to call iwdd.ipl for standalone datadeploy usage, you might want to take a look at this and see if it helps answer your questions.

It's more of a 1:1 mapping of old iwdd.ipl DNR scripts to new iwodcmd DNR script usage.

If you want to use dbLoader ... someone else will have to pitch in ;-) (I haven't used it myself)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mashboard.zip

Daniel_Cruz

Ghoti,

Thanks for your kind response. But our configuration is a little bit complex :-)

We are using the old "ddsync.pl" script (which dump TeamSite MetaData and TemplatingData to XML files, and load the XML dump files to a database) with dynamic input parameters, instead of using iwdd, as shown:

* DeployNRun tag (called by a workflow)
<dnrDeployment location="source" when="after" triggerPoint="transfer" state="success">
<script cmd="c:\iw-home\iw-perl\bin\iwperl.exe C:\iw-home\local\bin\od-dd\pcr_iwodstart.ipl $oddd_config^ -k area=$area^ -k filelist=$filelist^" as="" where="" async="no"></script>
</dnrDeployment>

* Second deployment (Data Deploy, name passed in $oddd_config^ variable)
<dnrDeployment location="source" when="after" triggerPoint="transfer" state="success" >
<script cmd="c:/iw-home/iw-perl/bin/iwperl c:/iw-home/local/bin/od-dd/ddsync.ipl c:\iw-home\tmp\dump_files op_pro loaduds full c:/iw-home/tmp/target_od/op_pro -Xldfn loaddb_op_pro.xml" as="root" where="c:/iw-home/OpenDeployNG/conf" async="no" >
</script>
</dnrDeployment>

So for us, an alternative path to <dbLoader> is using a equivalent "ddsync" script updated to version 6. ¿Do you know if there's one?

Thanks again.

crosstab (2).rptdesign

Adam Stoller

It sounds like dbLoader is the way to go for you - hopefully someone with more knowledge of the specifics for that feature will chime in here.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

aputnam

We too are in the process of upgrading our OpenDeploy to 6.0.2. I initially investigated the use of the dbLoader element but had to abandon it due to some of its limitations. Specifically, using the dbLoader element only certain types of configurations can be configured. Also, command line parameters are not passed through. In my case this did not work since I need some command parameters for my Tuple Processor.

Currently, our implementation is to do a deploy and run that calls a perl script. This script then calls DD in the new way by passing a DD config file and -k iwdd="myDeploymentName". Even with this approach I am having the same unique constraint issues you describe. If DataDeploy "thinks" a record is new it will always insert instead update the record. One solution we are exploring is to sync up the IWDELTRACKER table with all existing content so that DataDeploy will think it already exists.

Hope this helps.

Daniel_Cruz

Hi all,

First of all, thank you for your posts.

Looking at logs line by line and comparing them with DD 5.6 logs, we have found out that the queries built by OD 6 might be incorrect.

When we submit a modified DCR, DD 5.6 realizes that this row already exists, and therefore issues an SQL UPDATE. The version 6.0.2 does the same (finds an existing row and makes an UPDATE). It should stop creating SQLs here, but additionally it issues two more sentences after the last UPDATE: a new SELECT COUNT(*) and INSERT over the same key, which results in a duplicate key error.

We think that is likely a bug so we have opened a case. We will post any future solution.

Daniel_Cruz

Hello all again,

after some headaches, we have found the reason why <dbLoader> didn't work.

One simple lesson learned: "DO NOT USE DATABASE TRIGGERS WITH TABLES USED TO DEPLOY DATA IN DATA DEPLOY 6" (in particular, those "BEFORE" triggers that modify fields in the same record that you are inserting / updating).

Data Deploy issues SQLs selects to find out if it has to INSERT or to UPDATE a row. I haven't gone into this process in any depth, but Open Deploy does this SELECT COUNT(*) twice: The first time before the update, and the second time AFTER the update. The problem is: the second time the trigger modifies one of the fields and the second SELECT COUNT(*) returns no rows (looking at the DD 6 logs, the WHERE clause contains the old values before the trigger was executed). And thus the next statement is not an INSERT, but an UPDATE.

Our trigger changed a STATE field depending on the values of some dates into the record. We have moved this development into a previous JavaScript and eveything went well.

I hope this information could be useful.