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 find out not generated DCRs?

Ambuj

We are creating DCR and then generating ASP pages out of these DCRs. In some of the cases people are not generating ASPs so some DCRs remained orphaned in workarea. Is there any mechanism to find out those DCRs who are not associated with any ASP?

Find more posts tagged with

Comments

kaalraa

We are creating DCR and then generating ASP pages out of these DCRs. In some of the cases people are not generating ASPs so some DCRs remained orphaned in workarea. Is there any mechanism to find out those DCRs who are not associated with any ASP?

The only suggestion i have at first in my mind is parse each and every file and search for a common and unique value across the files.

If you didn't got a value of ASP in any of the DCR, then mark that DCR as orphan.

HTH

HideOuterGroupBasedOnInnerTable.rptdesign

Ambuj

The only suggestion i have at first in my mind is parse each and every file and search for a common and unique value across the files.

If you didn't got a value of ASP in any of the DCR, then mark that DCR as orphan.

HTH

This seems to be a very lengthy process. I was looking for some command or TS feature which can be useful.

But if we don't get anything, we will have to go for a long process of checking each and every DCR.

kaalraa

This seems to be a very lengthy process. I was looking for some command or TS feature which can be useful.

But if we don't get anything, we will have to go for a long process of checking each and every DCR.

File a feature request with Interwoven, so that every time an output file is being generated by a DCR it should get associated by itself using EA or such, automatically.

I strongly recommend for new designers/developers to keep this point in mind, so that once in a while one should not get stuck in such an issue.

Adam Stoller

We are creating DCR and then generating ASP pages out of these DCRs. In some of the cases people are not generating ASPs so some DCRs remained orphaned in workarea. Is there any mechanism to find out those DCRs who are not associated with any ASP?

You could create a FormAPI CallServer script that performed page generation every time the DCR is saved - or saved-and-closed - so that you would not have to worry about it.

You could examine the EAs on all the files that are not within the templatedata directory tree - to get a list of all the DCRs referenced by those files - and then get a list of all the DCRs - and compare the lists.

You could have the PTs set an EA on the DCR when they are used for generating an ASP page - and then look for all the DCRs that do not have that EA (I don't like this idea too much, because you are modifying the DCR during page generation, whereas page generation should occur after the DCR was last modified - but perhaps that's just me)

moonkhanna

the iwpt_compile.ipl -smartwrite option might be of help to you to do what you want..

Also, what do you want to do with the orphanised DCRs as of now... There might be a much simpler workarround depending on what you want to do.

Ambuj

the iwpt_compile.ipl -smartwrite option might be of help to you to do what you want..

Also, what do you want to do with the orphanised DCRs as of now... There might be a much simpler workarround depending on what you want to do.

I simply want to delete those DCRs.

Ambuj

the iwpt_compile.ipl -smartwrite option might be of help to you to do what you want..

Also, what do you want to do with the orphanised DCRs as of now... There might be a much simpler workarround depending on what you want to do.

I don't think "iwpt_compile.ipl -smartwrite" will be useful in my case. Can you please elaborate as how I can use this?

chetansethi

To me the best approach would be to write a perl script to get the extended attributes of all the generated files. This would give you the list of used DCRs which you can then use to find the orphan DCR (again in the same script).

moonkhanna

I don't think "iwpt_compile.ipl -smartwrite" will be useful in my case. Can you please elaborate as how I can use this?

You will have to write your own logic but if you run the above on all DCRs and capture the results i.e. wether it generates or not, you will come to know..

Of course, you need to be aware that even the modified DCRs will generate together with the DCRs which are orphaned..

Adam Stoller

You will have to write your own logic but if you run the above on all DCRs and capture the results i.e. wether it generates or not, you will come to know..

Of course, you need to be aware that even the modified DCRs will generate together with the DCRs which are orphaned..

The smartwrite option is, I believe, responsible for verifying if a newly generated file differs from a previously generated file so as to avoid modifying and updating the time stamp on the generated file if there are no differences.

The original question was to find all DCRs that were not used to generate a file - so I have to agree - the 'smartwrite' option probably doesn't apply.

A script that traverses all potentially generated files and checks their EAs to record the DCR to which they are associated - and then traverses all the DCRs and eliminates from contention those which match up to generated files - will get you most of the way there.

The big problem comes if the people who wrote the original PTs and/or page generation process didn't ensure that the EAs got set on the generated pages - in that case you would have pages that were generated from DCRs without any evidence - and those DCRs would be subject to removal on the (incorrect) premise that they weren't used to generate output pages.

Personally, I like to make sure that there's a 1:1^* mapping between DCRs and generated pages so that the filenames and paths can easily be associated with one another and the EAs are used for confirmation - and while that's a good plan for going forward - it doesn't help with the pre-existing conditions if no such logic was followed in the past.

[^* You can expand the process with N:1 mappings of output files to DCRs through naming conventions and through the use of EAs on the DCRs or some DB table to make sure the full association is recorded and maintained. Handling 1:N mappings, where a given generated page may be the result of content processed from more than one DCR, is a bit trickier, but again, if you plan it out before hand, it can be made to work]