Hi,
We have 3 different services hosted on webMethods environment. The trading partner profiles belong to these services will have different id types (user defined id types). We dynamically add Trading partner profiles in TN based on some events through a java service. Eventhough we set the profile status to Active in the java service the profiles are added with Inactive status in TN. In our environment tn.required.idType is always set to DUNS. I would like to know whether there is any way to set the profile status to active irrespective of the tn.required.idType value. Any suggestion would be highly appreciated.
Hi Kaviraj,
The service wm.tn.profile:addProfile always saves the profile as Inactive. After that, are you calling wm.tn.profile:changeStatus to change the Status from Inactive to Active?
Also, after calling the service wm.tn.profile:addProfile, check that there is no errors stringList returned. If there is errors returned from addProfile, then even if you run wm.tn.profile:changeStatus to change the Status from Inactive to Active, the TN will not make that profile Active.
IIRC a profile cannot be made active if it does not have the required ID set. You should always set the required ID, whether the profile is created manually or through automated services.
Even though you are adding profiles programmatically or manually,atleast one ExternalIDtype/value is required inorder to enable profile (Active).This is the standard behaviour of TN.
You can set the required ID type to a custom value. We are migrating from Gentran, and have decided to change the DUNS to an internal vlaue that resembles our old Gentran TP Profile ID. Find http://{TNPATH}/settings-tnProperties.dsp and make you changes there. OR… you can always fudge the DUNS if you have multiple profiles for each partner.
But typically how do we handle the very possible use case of each package deployed in the IS having their own External ID as required? As i understand it is defined in TN and so is common for all the profiles created in TN irrespective of the package dynamically creating it (or for that matter manually too). Wouldnt it hamper the other profiles getting created in TN.
For instance there are three required External IDs that are defined as required, say XYZ, ABC and DEF. Each External ID has been added as required by different packages. So there is very much possibility that not all profiles that are to be created would be able to define all the three External IDs. In certain cases, they might not even know what ABC - External ID is meant for. So in such cases how do we deal it?
Is there a way out in webMethods TN for this possible usecase or should it be considered as a design flaw from the users who define them as mandatory?
Hi Sriram,
You cannot have more than 1 external ID as the “Required”, only one is allowed to be “Required” at 1 time. You cannot have different packages deployed in the IS having their own External ID as required. It is a TN property, common to all the profiles and resides in TN properties file.
“But typically how do we handle the very possible use case of each package deployed in the IS having their own External ID as required?”
I must disagree with the notion that each package deployed might have their own external ID. The needed number of external IDs is typically fewer than 5 and is quite often just one or two (DUNS and Mutually Defined are the most common). It is also common to have one or two IDs from applications that identify partners–how many such applications do you have?
For TN there is only one external ID required. Never more than one. You can add all the custom external ID types you like, XYZ, ABC, and DEF and TN will still only ever require the one external ID. It is not possible, AFAIK, to configure TN to require more than one external ID for its profiles.
Each of your packages needs to understand what to set for the external ID type it wants and what to set for the TN required external ID.
“For instance there are three required External IDs that are defined as required, say XYZ, ABC and DEF. Each External ID has been added as required by different packages. So there is very much possibility that not all profiles that are to be created would be able to define all the three External IDs.”
Which would indicate those external IDs cannot be required, they must be optional. But as I mentioned, there is no way in TN to make all three of them required anyway, so the point is moot.
To sum up, you must set the required external ID for all profiles before the profile can be made active. There is only one required external ID. You cannot require more.