Running ICS for PDF 10.00.03.140
I have a drawing in ProjectWise has tags (example tag = "AAA") that are normally updated by Attribute Exchange whenever the document is opened. If the value of the attribute is changed ("BBB") in the ProjectWise document properties, then a rendition created, the resulting rendition displays the old value of the attribute ("AAA"). In other words, it is not automatically updated. If the document is checked out, a "Saved Settings" performed, and checked back in, a new rendition will display the correct attribute value ("AAA").
We expect the rendition to display the current values of its ProjectWise attributes even if the drawings do not have a "Save Settings" manually performed after the change.
Is there an environment variable that controls this? Any other options, or is this just a bug.
Is the title block in a reference? By default, iCS for PDF does not perform attribute exchange inside references, to avoid problems with concurrent extractors. Best practice is for title blocks to be in the master DGN.
Our border is a reference attachment. It contains "sheet tags" and "project tags". Sheet tags are copied into the master file for the specific sheet. Project tags are displayed from the reference attachment. Our title block is in the border because there are cases where a project is replicated outside of ProjectWise. In that case, the border is referenced to create a single point of update. The second reason is that the sheet files, even in ProjectWise, do not have to be burdened with project tag sets and their definition. For sheet tags, there is no way around that burden.
Warren J. MalveauSenior CADD Support SpecialistLos Angeles County Sanitation Districts
Reference attribute exchange can be enabled in iCS for PDF by adding a row with Name="PW_TITLEBLOCKS_SKIP_TAGS_IN_REFERENCES", no value, to the "rendsvcIplotConfiguration" table in the Orchestration Framework database, then restarting the ProjectWise shepherd service (or just rebooting). This assumes a default MCM configuration otherwise.
Be aware that when multiple rendition engines are configured (which is very common to improve performance), there is a chance that two or more engines (i.e. MicroStation.exes) will at the same time open different master DGNs that share the same reference DGN containing a title block. In order to perform reference attribute exchange, the engine is forced to briefly open each reference file read-write. If two or more engines try to do this for the same reference at the same time, all but one will fail and open the reference in read-only mode instead preventing title blocks from updating. No error is given when this occurs.
Thus, in a typical deployment, reference attribute exchange may work most of the time but can never be completely trusted. This is why the feature is disabled by default, and best practice is to keep title blocks in the master DGN where there are no file locking issues.
Was this issue resolved? I have a similar issue - I have a DGN sheet with referenced border line work but the title block tags and tag sets are in the master DGN file. I can update the PW attribute data, save and then rendition but the values are not shown in the PDF. If I open the file for edit, they show. If I check it out and check it back in and then rendition, they show on the PDF.
Does the non-GUI rendition engine (MicroStation CE in this case) open the file for edit or read-only? As expected, if the file is opened for RO the tags do not update.
We recently updated to CE OrchFwrk and CE MicroStation from V8i
Should I expect the rendition server to update the PDF with the attributes from PW even though the DGN may not have those values?
It was not. We filed SR-7000922791 Current status is "Under investigation"
Our workaround is to check out documents that directly display (not reference) the affected tags, do a “Save Settings”, then check back. Typically that means that we open our border file directly, do "Save Settings", then check it back in.
Also established a rule that if any exchanged attributes change in ProjectWise, the above procedure must be performed.
A possible solution with certain server / software configurations is to set the rendition account from No Expiration to Server Default. This one change fixed all our rendition issues on that server. Bentley is investigating - may have something to do with No Ex accounts interacting with the Connection Client.
Hi Dave, What is the integration & orch. service version you are running. We have established that it works in 10.00.02.265 (table entry addition) and 10.00.03.262 (front end setting in Orch. Framework Admin 10.00.3253) as Andrew has mentioned. For some reason 10.00.03.140 is not accepting this. We are currently checking this and positive to reach conclusion tomorrow.