How to get ufid from an EPMDocument without using Info*Engine?

[PeterWigren]

Hello!

This is my first question as I'm starting to explore this community.

Hopefully I will not screw up in the fora, but please bear with me if I do.

So now to my question:

Does anyone happen to know how to get the ufid from an EPMDocument using Java in Windchill 10.0?

I know how to get the short version obid (wt.epm.EPMDocument:1998846842) but not the long one (VR:wt.epm.EPMDocument:1998846842:981783618-1249579887230-31922233-43-20-97-131@vpdmtest4.got.volvo.net) which I have only seen in Info'Engine output according to below:

The reason not to use Info*Engine is speed due to large volumes.

Any help would be appreciated!

Cheers!

/Peter

[JørnAHansen]

Hi Peter,

Welcome to the community from a fellow Scandinavian!

If using the Java API are you then sure you need the extra :<some looooong number> @ <windchill-domain-name> part of the long form?

... So I'm curious what your use case is for needing the long form?

The reason I'm asking is that as far as I have seen (and can remember) that part of the obid is the same for all Info*Engine responses you receive for a given Windchill installation. Another experience I have is that for some I*E requests where I had to give an obid as parameter I even had to cut that part off to get Windchill to understand my request.

Unfortunately I have no documentation to back up these observations of mine. If your use case requires you to supply the long form I guess you could always make one I*E request to get it and then add it with manually pasting the Strings together if that is not too hackish for you ;-). That way you could replace lots of I*E calls with one I*E call followed by lots of Java API calls.

I have one data point though, which I just dug up on a hunch triggered by your post. In at least one of my systems it seems that <some looooong number> matches the guid and <windchill-domain-name> matches lastKnownDomain in row with displayName = Windchill in the REPOSITORY table of the database. This *might* back up the fact that this is static for a given Windchill instance. If it's available through some sort of API I do not know.

Cheers (or Skål),

Jørn

[PeterWigren]

Hello Jørn!

Thanks for the warm welcome!

The reason why we need the long id is because we are bridging information between PDMLink and another system. Since we have a few PDMLink installations I believe the long id was chosen to distingush between them.

I also believe that the long id is more accoding to the PLMS spec.

Seems that your observations are accurate. I have not done some extensive tests but it seems the long id is always built using the short id followed by the same string no matter what object is retrived in the I*E task so I plan to do as you suggest, make an I*E search for one object and then copy paste it to the bulk data.

Thanks for the tip!

Best regards,

Peter

[Amit_Kumar]

Hello Peter,

We may use

import wt.federation.FederationUtilities;

Object obj = FederationUtilities.getObjectByUfid(oid);

Regards

Amit Kumar

[PeterWigren · Accepted solution]

Hello Amit!

Thanks, but the intention is to extract the Ufid from the EPMDocumentMaster, not to obtain the EPMDocumentMaster from the oid.

However you have directed me on the right track:

By using:

EPMDocumentMaster master = getMaster(filename);

String ufid = FederationUtilities.getUfid(master);

It is possible to obtain the ufid.

Best regards,

Peter