Has anyone used the File/import , File/export functionality in TN Console to successfully copy settings from one TN server to another? There seem to be problems with using it for change management (say, for copying a TN partner profile or processing rule from test to live):

1. When you export a partner profile, the exported XML file contains certificate settings from the source machine. These would be wrong on the target machine. eg:

value name=“Certificate”>config/certs/b2btest.cert.der
value name=“CACertificate”>config/certs/thawte.crt
value name=“PrivateKey”>config/certs/b2btest.private.der

2. While copying partner profiles, Extended Fields are not copied to the target profile.

3. While copying processing rules, the sender id is copied as well but as a internal id that has no counterpart on the remote server. eg:

• array name=“SenderID” type=“value” depth=“1”
  value>ac100177f70d6b6a00000153
  value>ac100177f70d7a8600000388

Some more results - If you export a processing rule between servers, they do import fine enough into the target server.

However, since the source server had SenderID values like:
value>ac100177f70d6b6a00000153
value>ac100177f70d7a8600000388
…which are unknown on the target server, the imported processing rule description now say that the sender Id is “null”. Furthermore, you cannot view or change the imported processing rule, only delete it. You can modify the exported XML file, but this is completely non-intuitive and you still need to check for errors.

So the import/export functionality for processing rules and profiles is limited to the same server. i.e. its pretty much useless for change management.

Another thing we noticed is that Document Types cannot be imported. Though we were able to export a Doc Type from the source IS, the subsequent import to the target IS gave an error that said:

“File is not a valid IDataXML Coder file. Fix file or select another file.”

This is problematic because processing rules are often dependent on document types being created. So it does no good to import processing rules if the doc types it depends on are not imported.

Sonam: How was the profile created in the target server? Was it created by hand or was it imported as well? I’m curious to see if the internal ID is exported/imported or if an imported profile is assigned a new internal ID.

Rob: Most of the target server profiles were created by hand. As Rajesh says, if we cannot export document types, we cannot export processing rules either since they refer to doctypes by internal IDs.

I still don’t know whether, when an import/export is done:

• EITHER fresh internal ids are created on the target
• OR internal ids are copied from the source.

Sonam,
To my experience when you import, the same internal IDs are copied over. I used to have issues with internal ID’s of External IDs, Extended Field Groups, etc. So I edit them manually and import the file again. I guess that is true all over.
Also, if the internal IDs were re-created, then those elements refer to those IDs within a profile will go invalid.

Thanks PU ! Editing the fields in the exported XML seems to be the only way import/export can be carried out. The issue is the effort in modifying the exported XML file tag by tag - a problem for large exports. So , I just do this manually for now. I wish WM would address this issue long term.

Following up on this thread.
Did anyone confirm that when you export Extended fields if the values can be taken with it?
I just tried it and the values were not included.
Can someone please confirm.
Thanks.

Hi Chris,
When you export the extended fields, I don’t think values can be taken with it. However if you define list of possible values while creating them, that goes with it. Still you need to set it them after importing.

When you select to import a processing rule, Trading Networks checks to ensure the target Trading Networks system and/or import file also contains the dependent document types. Dependent document types are the document types included in the Document Type
criteria in the processing rule. If the dependent document types are not available, Trading Networks issues a message and allows you to decide whether you want to continue with
the import.

webMethods Trading Networks–Building Your Trading Network - Page 310

Rumor has it (I think it was on another thread?) that if you use the command-line version of export/import, the extended field values get handled right. We’ll be testing this out in the next few days. I’ll post our results.

Wow. TN export/import for migration is quite a chore, as everyone in this thread has pointed out.

The command-line version does indeed have a switch (-extflds) for handling extended fields. But it doesn’t appear to have any way to be selective–it’s all or nothing for the type of TN component you choose to process. It also appears to be a recent addition to the utility. A slightly older version didn’t have the switch.

The UI in TN console is selective, but it doesn’t support exporting extended field values (definitions are no problem).

Basically, if you want to be able to migrate from one environment to another, the target environment should never have anything defined to it directly–only via import.

Sonam mentioned in another thread that a ‘diff’ utility would be great. I agree. We need one!

Rob,

Where’s the command line version, and what version of wm are you on? Where did you find the info on the command line version.

Thanks.

It’s in packages/WmTN/bin
4.6
[url=“wmusers.com”]wmusers.com

Run tnexport.bat with no parameters to get a list of args.
The -extflds will be listed if you have the right version.

Rob,

Thanks. I was looking for an exe file not a bat file. Thanks for the link also.

Here we go again?
I have been trying to build a QA box for while now. IS 6.01 w/ SP2. W2K w/ SP4 and SQL Server 7 with SP4. Same as my DEV and PROD environments. I trying to duplicate my PRD setup in QA. To that extent I exported my TN data using the command line tnexport.bat. The files profiles and flddefs import fine. The extflds import but I do get this error which tech support is telling me that I can ignore it.
(7) 8e462bebf70d810000000199 TP_AbrvCode
field TP_AbrvCode (8e462bebf70d810000000199): java.util.MissingResourceException
: Can’t find resource for bundle com.wm.app.tn.resources.ProfileMsgRes, key TRNS
ERV.000012.???
at java.util.ResourceBundle.getObject(ResourceBundle.java:370)
at com.wm.app.tn.err.SystemLog2.getResource(SystemLog2.java:106)
at com.wm.app.tn.err.SystemLog2.getMessage(SystemLog2.java:121)
at com.wm.app.tn.err.SystemLog2.format(SystemLog2.java:348)
at com.wm.app.tn.err.SystemLog2.format(SystemLog2.java:268)
at com.wm.app.tn.db.Import.installExtflds(Import.java:472)
at com.wm.app.tn.db.Import.installData(Import.java:107)
at com.wm.app.tn.db.Import.main(Import.java:842)

I can query the tables and see that my data is present but when I run TNConsole it’s a different story. None of my Extended Field Groups are visible. Some of my own extended fields are appearing under the EDIINT group. I have rebuilt the system about 4 times. I have dropped the TN tables and recreated them about 10 times. Tech support even sent their scripts and that did not work.

The data volume is low and I re-key if I have to. After all it’s only a QA box but then I’m wondering if something else is broken that may crop up later.

Any ideas?

TIA

I advise to use webMethods Deployer 6.1 or 6.5. It’s much more powerful and allows selective export and imports. The only drawback is that it exports only in binary format. Sorry no xml. I hope this helps anyone.

You can use the tnexport and tnimport scripts in the /packages/WmTN/bin directory.

Is there any documentation around these /packages/WmTN/bin scripts? Has anyone used them successfully?

Found a link on this site which talks about this feature in more details. I’ll try that out and see where we land:

[url]wmusers.com