Does anyone have a good naming convention for TN Processing Rules ? I’m looking to use the TN Console Export and Import facility to move them between our dev. and production environments. The documentation says that when they are imported, they will create
duplicate entries, if they already exist in the same environment, and also will be appended to the end. I am looking for a scheme, so that the updated rules will become obvious in the list, and can be moved to their proper location. Does anyone have any experience with this ?

Hmm… from what I recall, the TN Import/Export facility is next to useless since it uses internal IDs in the exported rules. For example: ABC Company may have Internal ID: “aa” on your dev server but “bb” on your prod server. In the processing rule export from dev to prod, ABC Company will be represneted by code “aa” instead of “bb”. The same problem exists for document types.

Take a look at the archives for a discussion on changing the exported file manually.

About a naming convention for TN processing rules, how about this:
{Workflow_Direction}-{Document_Standard}-{Custom_Processing} ?

The label at the end would be for rules doing special processing.

For eg: “wfin - xCBL 3.0” or “wfin - xCBL 3.0 - XXX Marketplace”

Hi Brad,
Instead of doing a full export you can do a partial export of processing rules only. It surely creates duplicate entries but you can delete them as they occur at the end.
Another option would be to delete all processing rules and export/import of processing rules only.
But in case of document types and document attributes the webMethods pops up messages stating whether to overwrite the existing ones.
Hope it helps

I believe this is only an issue if you create profiles and/or doc types by hand first in each environment. If you export things and import them into a server that has no definition for the items being imported, then you’re fine.

Doh! Thanks Rob & Brad. So its possible to delete profile, doctypes, and processing rules on a server and reimport it from another server?

I am now thinking of killing off the doctypes, profiles, and processing rules on my dev and test servers and importing them from live. By doing this, I could use TN import/export to make changes from dev to test and to live and everything would always be synchronized with no problems - correct?

Do you see any problems with this approach?

One problem I can see is our servers have some C1-Onramp document types that cause the following errors to be thrown during export: “The class for the document type is not found in the classpath. Please make sure that the classpath is set up properly.”

I guess the C1-Onramp doctypes should not be deleted on the dev and test servers.

Hi sonam ,
You approach is right.
I have faced problems in doing a full export and then doing import. If u face any problems export profiles,doc type & processing rules separately.

I also got classpath error but it doesnt hinder the export operation.

Thanks for the tip John! I’ll give this a go when I setup a new dev server.

I have a related question: If someone needed a tool that worked like Unix ‘diff’ - only it compared the TN setup (profiles, processing rules, doctypes) across two IS servers instead… can anyone speculate how one could go about creating this utility?

I was thinking maybe TN information could be programatically “exported” (like we do manually in TN Console File/Export), and the exported files of two servers compared. Would this work?

Thanks for the info!

Brad

For john - if you’re getting ‘ClassNotFound’ errors in your TN console, it’s most like the classpath setting in your console.bat file under the TNConsole4/bin directory. The jars you use for EDI, RosettaNet, etc have to be in your classpath.

This also goes for any custom objects you’ve created - when you step through a flow in the developer you would see null for an object since it’s not in your local classpath (for the GUIs)

Hi,

When migrating TN exports and IS packages to production,
what is a good way to disable processing of documents
related to the change prior to the install, and then
reenabling processing and reprocess any documents after
the install is complete ?

Brad

There is only one suggestion for TN Processing Rule Naming Standards here. Anyone have any suggestions?

Our business involves multiple exterior Partners (>1200) and multiple interior Partners (> 10 business units). Docs, including EDI with many versions, CXML, XML, etc., are delivered to and from all.

thanks

PartnerName TO|FROM PartnerName [DOCTYPE] is what I have seen used in the past. For example, “AcmeA FROM AcmeB EDI850” or “AcmeB TO All RNPartners RNAck”

However, it normally breaks down over time and you come to rely on the descriptions…

I also agree with Phil’s suggestion above, followed same type of naming pattern/annotation,and also putting more notes in Description seciont also makes easier for any developer/analyst to digest.Rule name should be easily idetified based on its job whats it is primarly triggered for invoke.

HTH,
RMG

Agree with Phil’s suggestion… also suggest ‘customization’ scope be appended to the end of the rule, with generic rules positioned below customization-specific ones.

Perhaps something like this would suffice:
- -

Eg:

In - xCBL 3.0 PO - Platform - ABC
In - xCBL 3.0 PO - Customer - XYZ
In - xCBL 3.0 PO - Generic 
Out - xCBL 3.0 PO - Generic