cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

Bursting Configuration

ptc-2268933
2-Explorer

Bursting Configuration

Hello All, new to the board, so any advice would be appreciated.


I'm trying to recreate our parent company's approach to our PTC solution, however our communication with them is limited.


In doing so, I can begin to revise their approach and procedures for our needs and build our Windchill ditabase. We receive their XML files for our manuals, and I obtained a copy of their custom folders with their stylesheets. I also received their bursting rules. When I try to burst a book from the map level, it comes back with an error saying, "Cannot modify the following attributes: lang, because they are not defined. I'm still a novice, although I have gone through all the AE and WC PTC courses I can go through, but I'm not sure where to fix this issue. The attributes are defined in the bursting rules, I see language under the attribute root in the Type and Attribute Mgr in WC, and it is a valid element attribute in the dcf. Where shouldI look, or should I post this in a better suited forum?


Thanks


Another question. If you're realtively new to the PTC family, and you have gone through AE, WC and Styler courses from PTC and read through a lot of their manuals, where would you look next for additional training and understanding? A lot of these courses teach basic application, but not understanding of what to do.


Thanks again!

16 REPLIES 16

I don't think there are a lot of hands-on, button-clicking classes you can take. Probably one of the best things you can do is what you are doing right now: ask the Adepters. Trial-and-error and asking questions here may turn out to be your best bet.

Hi Bryon,

You may need to upload the burst config file(s) to the Windchill
server from Editor (Save as Server Object), usually in a Library
that other users also have access to.

Regards,
Richard

I might try that. Up until now, I have been using the APTOBJCFG environment variable.


I'm responsible for the Windchill server test, and I have hesitated uploading the burst files to windchill at the moment. The reason is, once I successfully upload books to windchill using my parent's system, I plan to blow them away and reconfigure the bursting rules and dita filesto build a simpler, more reusable library. Unfortunately, our parent company bursted their files too deeply for acceptable reuse on our part. Although, I could upload the burst files and change them over, I just didn't want to add another variable to the plate.


Is there a difference in using the environment variable versus uploading the burst files to windchill?


Thanks

Alessio
15-Moonstone
(To:ptc-2268933)

Thomas,

You have checked for the attribute in three places:


1. In the bursting rules (in a section like the following):
<dmsobjtype>
<typerule elementname="topic" targettype="WCTYPE|wt.epm.EPMDocument|PREFIX.DynamicDocument|PREFIX.Topic"/">
</dmsobjtype>

<dmsmetadata>
<metadatarule elementname="topic" expr="@xml:lang" metadata="lang"/">
</dmsmetadata>


2. In the Attribute Manager in Windchill (it has a name, internal name, and description)

3. In the .dcf

There is a fourth place where you should reference it: in an actual type defined in the Type Manager in Windchill: just defining an attribute is not enough, you should also tell Windchill in which types that is attribute used.
In this example a topic is burst as a PREFIX.Topic type in Windchill (see burstspec snippet above), hence this type should use that attribute: you need to add a global attribute to that type, picking the attribute defined in the Attribute Manager.
The rationale for having first to define an attribute in the Attribute Manager, and then reference it from a Type, is that you might want to reuse the same attribute in multiple types with different constraints for each type.

See Help Center:

* Windchill 10.0:

Hi Bryon,

I'm pretty sure APTOBJCFG is only for pointing to atidefaults.xml which is the basic bursting defaults. The doctype-specific burst rules are usually in the doctype folder itself (as a .bcf file) or as Richard said up in Windchill.

Cheers,
Gareth

Alessio,
Saw your response - thank you for taking this time to help!
Cindy

Hi Gareth--



Actually, if APTOBJCFG is defined, then that's the ONLY place the
Windchill adapter will look for ANY burst rule files. If it's defined,
then any burst rule files that are checked into Windchill are ignored.



To see what burst rule files are actually loaded by the adapter:



1) Establish the WC connection from Arbortext Editor

2) On the Arbortext command line, type
"response(wcconfig::findBurstConfigFiles())"



That can help you determine if you are inadvertently loading the wrong
burst config files.



--Clay





Clay Helberg

Senior Consultant

TerraXML



Hi Clay

How do I use TerraXML to automatically burst documents in Windchill?

Hi Clay,

Great debugging tips!

I don't know if it's relevant to the OP or not but I checked one of our projects and it seems APTOBJCFG may be used in conjunction with regular doctypes .bcf files. Eg. we have an atidefaults in the location indicated by APTOBJCFG and the adapter is also picking up doctype-specific burst files from the relevant doctypes folder in the APTCUSTOM location.

-G

Hi Gareth--



That's interesting, I'd like to see how that works. If you look at the
code in wcconfig.acl (in adapters/com.ptc.prowt.arbortext/init), you can
see that it explicitly skips looking anywhere else when APTOBJCFG is
defined. I'd be curious to see the output of the command I mentioned for
that project to verify that it's picking up the burst config files from
both APTOBJCFG and the doctype directories.



--Clay



Clay Helberg

Senior Consultant

TerraXML


Alessio,


Thanks for the tip. I tried that, and it didn't work. Not your fault, I checked the lang attributes in the xml book, and noticed there was 1 that was an undeclared .psu file for british. I reverted the profile back to the original (I translated it from japanese), and that error stopped popping up (the undeclared element is still there, but it can't understand the profiling so I don't think it's trying to anymore).


However, since this book is a zipped book from the parent company's windchill, the files are still saying they are dependent on each others revision levelsto upload (Since some pulled from different books). Here is an example below. How do I prevent the books from carrying this, since for my new database they would all be A.1 anyway? The error comes back with a different referenced file every time, I assume because they are all dependent.


Also, would my windchill have a problem if the master language defined in wc is english, and the master language of the xml files was japanese (translated to english as xml:lang=en)?

You didn't direct this email at me, but it occurs to me that you may have a simple way to load the content into Windchill. Just take each XML book, load it into Arbortext Editor and (assuming doctypes/bursting/etc. is good) do a "Save as Server Object" from the File menu. That will create an object for the document (and related objects for graphics, burst chapters, etc.). Those would then all be at A.1 revision.

AFAIK Windchill does not ship with any translation management capability so the difference between a Japanese master and English variant would be irrelevant?

-G

I'll have to keep playing, rather than ask a question and keep trying.


I added an elemename to the locnrule to operatormanualmap, and every document that did come up appeared as operatormanualmap in WC. I was only trying to have the map burst as a map. I'm still unsure how to burst the rest into their respective types (reference, etc.). Right now, my locnrules graphic and text have no elementname associated. That seemed to be the way they came in.


My current issue is "checkin failed 1 conflict: K03_UWGM_NEVER_BEEN_UPLOADED:null" has me stumped. I will update if I figure out what that means.

Gareth,


During this whole test, I have a copy of the xml book and it's files all in one folder on my client. Everytime I make a test after changing the burst rules, I connect to my WC, and save as server object. That's where I keep getting different errors, like the one concerning language attribute, and the one concerning the revision levels. Every once in awhile, WC will upload a small bit of the files into my workspace, but they aren't in the library (although all attempts made every file an operatormanualmap). That's when i removed the operatormanualmap elementname from the locnrule. Now I get the error I just posted before this one.


This is a doozy for me!

Update:


PTC and I were able to modify the bursting docs enough to get the books to burst to windchill. The files have the correct softype, although that's really as far as we have gotten.


I'm wanting to understand and possibly undo a lot of the id referencing the parent company did. I'm still not experienced in understanding metadata rules well enough. Can someone tell me in general what these metadata rules are saying? For instance, I know that they're saying within elementname reference there is an expression listed, but I still don't understand what they are doing with them in WC. Just listing them as WC attributes, maybe? In the test with PTC, we had to remove these rules to get the book to burst, which makes me think to use them I'd have to add info in the Type manager, but I need to see if I need them in the first place. Thanks


<dmsmetadata><metadatarule elementname="reference" expr="child::title"metadata="WC_NAME_ATTR" sourcetype="text"/"><metadatarule elementname="task" expr="@outputclass"metadata="positioncode" sourcetype="text"/"><metadatarule elementname="reference"expr="/reference/titlealts/navtitle/partnum" metadata="dmc"sourcetype="text"/"><metadatarule elementname="reference"expr="/reference/titlealts/navtitle/term" metadata="category"sourcetype="text"/"><metadatarule elementname="reference"expr="/reference/titlealts/navtitle/ph" metadata="variant"sourcetype="text"/"><metadatarule elementname="reference"expr="/reference/titlealts/navtitle/tt" metadata="situation"sourcetype="text"/"><metadatarule elementname="reference" expr="@xml:lang" metadata="lang"sourcetype="text"/"></dmsmetadata>

Bryon,

Basically what the metadata rules are about is to define how content of particular elements or attributes from XML is stored as metadata on the corresponding Windchill object. There they can be used for Search etc. The key in your sample data below is the "metadata" attribute in the metadatarule elements. This attribute defines the Windchill attribute where this particular content will be written to. And if that particular attribute is not defined in the Windchill Typemanager bursting will not work.
For short the explanation of the attributes in the metadatarule element:
elementname = when bursting encounters this XML element that particular rule will be evaluated
expr = this is an xpath expression relative to the XML element given in "elementname". The result of that expression will be saved to the Windchill attribute
metadata = the name of an attribute in Windchill. The attribute must be defined and attached to the soft type used for storing your XML file
sourcetype = can be either "text" or "graphic", defining whether metadata shall be stored from a text document (XML) or a graphic which is referenced inside the XML

That said your set of rules below gathers information from different elements/attributes in a reference topic when that topic is stored to Windchill and tries to write that information to different Windchill attributes on the object that represents the reference topic in Windchill.

I hope that sheds a little more light on how the metadatarules in the burstspec are working.

You can find more information in the Arbortext Helpcenter in the Content Management Guide/PTC Server connection document bursting/Assigning PTC Server properties

Kind regards

Sirko





[Description:
Announcements

Top Tags