Custom Transformation service in TN

Hi,

I’ve a problem in identifying an XML docType coming into TN.

I’ve created a docType in TN identifying the document using docTypeName = “ShippingInstructions” and recOrdId = “abc”.
Multiple senders can send this document to TN, so the value changes in sendOrgId (It can be asd, 123 or anything). In docType
in TN, while extracting the senderID, I want to create a custom Transformation service which can transform all the receivers
into one receiver for ex “xyz”.

I created a custom transformation service using the specification “wm.tn.rec:StringAttributeTransformService” for inputs and
outputs.

I’m receiving the correct value in inputs (ex. asd, 123 …) and hardcoding the output to xyz. I guess I need to validate
this xyz with externalID fields. I don’t know how to do this.

Can someone please help in this issue.

Thanks in advance,
Daya.

It may be easier to just ignore the receiver in your rules. If the receiver doesn’t matter, then just ignore it by setting the rule(s) to “Receiver = any”.

What leads you to feel that forcing the receiver to be a particular receiver is the way to go? What basic issue are you trying to address with such an approach?

Thanks for the reply Rob.

I was able to process setting the Sender and Receiver to ‘any’. But my wM admins wants to see some value in sender and receiver fields in Transaction Analysis. If I don’t extract the sender and receiver, it is showing as ‘unknown’ in Transaction analysis.

I resolved this by creating custom services. In custom services, I hardcoded the internalID’s of Sender and Receiver. It worked fine… Now what ever the value comes in Sender and Receiver, it shows the values in Transaction Analysis.

Thanks for your help though.

Thanks,
Daya.

So instead of the real sender and receiver the transaction analysis is showing hard-coded and bogus sender and receiver? So for that document type, the sender and receiver will always be shown to be the same, even though the real sender and receiver may vary? To me, that’s worse than “Unknown”.

The desire of the wM admins is presumably to be able to search for documents when trouble occurs. When looking for a document, admins will ask when the doc was sent (or an approximate time to narrow a search), who sent it, who it was to, the doc type, etc. If for this doc type the sender and receiver are always the same in transaction analysis, but the “real” sender and receiver vary, then it does two things: 1) searching by sender and receiver becomes useless, just as it would be with “Unknown”; 2) there is an illusion that the sender and receiver are known, when they really are not.

Clealy I’m not aware of all the details of your particular situation, but with the information given, this “solution” seems very, very odd.

I agree with you to some extent.

My scenario is something like this.

My company is ‘A’ and have a partner (Integration provider) called ‘B’ and external partners as ‘X’, ‘Y’, ‘Z’ and some more.

X, Y and Z sends documents to A via B. So A receives the document from B, but the document has sender ID’s as X, Y and Z.

I defined Profiles for A and B in TN and defined one docType. Now who ever the sender is X or Y or Z, I don’t have an option to show X, Y or Z’s sender ID’s in Transaction Analysis Sender’s column as I created profile for B. So I created custom service to display B in transaction analysis even if I get the doc from X or Y or Z.

You might consider the following:

  • B is not a partner but a transport hub/communication path. B should not have a TN profile.

  • X, Y, and Z are the partners and the TN configuration should reflect that. The fact that they are reached via B, or files are received from them via B, is important only at the communication level.

  • The X, Y, and Z profiles would all have the same communication setup–an FTP or HTTP address to send/exchange with B.

B isn’t the important entity here. X, Y and Z are. In other words, the VAN isn’t important–it’s the entities on the other side of the VAN that are of interest.

I’ve encountered this scenario many times, primarily with EDI, but also with XML exchanges. The “integration provider” is not a trading partner. Indicating that a document is to or from ‘B’ is outright incorrect, IMO. The document extraction should be configured to properly identify the actual senders, not the communication intermediary.

I agree with your suggestion Rob.

We have more than 150 partners and exchanging 18 docs. So my company didn’t show much interested in creating so many docTypes in TN.

In reality Rob’s suggestion is the way to go…It gives more visibility wrt TP’s exchanging docs and Transaction Analysis page aswell…

Anyways its not in your hands…big bosses must also show interest…:slight_smile:

HTH,
RMG

18 doc types is trivial.

150 partners may seem like a lot, and the data entry is tedious, but it isn’t that big of a deal. A day or two of data entry will be repaid many times over in increased ability to find sent and received documents by partner.

I guess my point really is, if the partner displayed in the TN transaction analysis is meaningless anyway, why does it matter if it says “Unknown” for the sender/receiver? Why create a custom transformation to show some other equally meaningless text?