Questions or comments about this webMethods Ezine article?

Click here to read the original text.

Sonam,

Great article! I havn’t completely digested all of it yet but I have a question. I’m currently in the development stage so my testing is not complete but what I’ve done so far is to create my service that accepts the ftp document and then the service post the document to TN via http to tn.receive.
My documents get recognized correctly.

Do you see any danger in doing this? Have I over simplified the process?

Thanks.

Chris

Hi Chris,
Instead of doing HTTP post to the wm.tn:receive, I would recommend calling wm.tn.doc.xml:routeXml to submit to TN from your service after accessing the FTP file.

Hi Chris and PU-

I don’t think a two-step FTP receive is needed. You can simply submit a document directly to the improved generic ‘receive’ described in the article. Both WM’s ‘wm.tn:receive’ and the new ‘receive’ can receive documents directly via different transport methods - HTTP, FTP, email, etc. A WM IS service just returns a generic WM “success” or “failure” status – the WM port handling the transport (HTTP/FTP, etc.) then translates this status as appropriate to the protocol used.

I did some experimenting: I setup an FTP port and added ‘wm.tn:receive’ and my generic ‘receive’ service to the access mode. Then I submitted a valid XML document via FTP, first to ‘wm.tn:receive’, then to the new ‘receive’. The TN database was offline during this testing, so an error code should have been returned.

The FTP session is below, with my notes:

ftp> cd ns/wm/tn/receive
250 CWD command successful.
ftp> put a.xml
local: a.xml remote: a.xml
227 Entering Passive Mode (172,xx,xx,xx,8,230)
150 Binary mode data connection for a.xml (172.xx.xx.xx,0).
226 Binary transfer complete.
7966 bytes sent in 0.000141 secs (5.5e+04 Kbytes/sec)

NOTE 1: wm.tn:receive incorrectly returns the regular FTP 226 status: "Closing data connection." 

ftp> cd /
250 CWD command successful.
ftp> cd ns/CorporateExpress/receive
250 CWD command successful.
ftp> put a.xml
local: a.xml remote: a.xml
227 Entering Passive Mode (172,xx,xx,xx,9,3)
150 Binary mode data connection for a.xml (172.xx.xx.xx,0).
550 [B2BSERV.0071.9014] Server Error:
7966 bytes sent in 0.000162 secs (4.8e+04 Kbytes/sec)

NOTE 2: The 'improved' receive service returns FTP code 550: "Requested action not taken." 

If an Email port is to be used, you can use the “Send reply email on error” option to email the document submitter when the submission had an error.

A point to note is that ‘routeXml’ should not be submitted a document directly since it does not do ‘Sender Verification’. The TN Programmers’ Reference guide has this to say about routeXml:

“This service does not check the identity of the sender against the currently logged in webMethods user. Only invoke this service from within processing rules or services; do not expose directly to trading partners.”

Sonam,
I totally agree with your point. I was not sure why and how FTP access was done that way, so I just commented on internal submit rather than HTTP. Yes, you are right. Wm has a FTP like interface to receive files into TN directly. I think you setup a FTP port and do the FTP there.
Coming to accessing the routeXML, I said, internally invoke (call in his FTP access service). If he already have accessed the file, why do you want to check the identity of the user again?

Sonam, Pu

The reason I’m ftp’n to myService vs. tn.receive is that I could not get syntax to work on specifying the application type. I’m working with EDI files and when I tried
put file.edi; application/EDIstream

the put failed.

With my service I don’t have to worry about the application type as it is setup to handle EDI files directly. It takes edidata object as input. I then post to tn via http.

Can the updated tn.receive take an EDI file?

Chris

Type putting

application/EDIstream edi

in the IS lib/mime.types file. This will tell the FTP handler to map files of extension .edi to that content type.

I think you have to restart the server after changing this file, but I am not sure.

Fred,

I already have applicaton/edi edi in the file so FTP can handle .edi files. My problem was tn.receive would not work with the ;application:edi as documented on page 17 of the EDI Core 4.6 manual. To be fair that example did reference tn.receive but myService.

I’m really curious as to what is needed to make it work with tn.receive

Chris

Hi Chris - I see now why you are using another layer. However you should be able to call the new receive service via a flow invoke from your frontend service, instead of doing a HTTP post. Is this possible? The input to the new receive is a ‘node’.

> Can the updated tn.receive take an EDI file?

I haven’t tested it with EDI files, but the new receive should be a ‘drop-in replacement’ for wm.tn:receive. i.e. if you get wm.tn:receive working with EDI/FTP , the new receive should work too. One thing you may want to modify is the branch at the top checking for the existence of a $xmldata variable (to let you test the service from a webpage.)

Hi PU -
> Coming to accessing the routeXML, I said, internally invoke
> (call in his FTP access service). If he already have accessed
> the file, why do you want to check the identity of the user
> again?

If a user has accessed a file, he has logged into the FTP server and is an authenticated user. However, TN still determines the document sender and receiver by parsing the document. So we have to make sure that the the user submitted document named him as sender (or that the user is an authorized VAN as described in the article). Page 2 of the article describes why we have to do this (“see the section on Sender Verification”)

Addendum to article:

Note that in the package download associated with this article, you must set the new “receive” service setting to “stateless”. This is to prevent WM-based clients getting session timeouts when posting to this service.

This was discussed here: [url=“wmusers.com”]wmusers.com

Addendum 2 to this Article: WM released TNS Fix 30. Here’s the description:

“- Trading Networks now notifies the document sender of a
document persistence failure. (TNS_4-6_FIX_30)”

This should address “Problem #2” from the article.

This fix is also part of TN 4.6 SP1. I haven’t tested the fix myself. I also don’t know of anything similar for lower TN versions.

Just a comment on the built-in wm.tn:receive service as of v4.6. receive calls ‘wm.tn:recognize’ and ‘wm.tn:submit’. The submit service calls ‘wm.tn.doc:checkUser’ which is supposed to return a ‘success’ parameter. If success= false, there is an EXIT and signal FAILURE step. When I stepped through the receive service after sending an XML file with a sender that didn’t match the logged-in user this parameter was not in the pipeline, so the flow continued on to the ‘wm.tn.route:routeBizdoc’ service. I would call that a bug which I understand has been fixed. You will have to change your flows if you install the service pack, since you’d have to catch the new exception instead of looking in the bizdoc for errors.
Will

Will

Hi Will -

I just read your comments?
> Just a comment on the built-in wm.tn:receive service
> as of v4.6. receive
> …
> service. I would call that a bug which I understand has
> been fixed. You will have to change your flows if you install
> the service pack, since you’d have to catch the new
> exception instead of looking in the bizdoc for

Just a question - your comments don’t apply to the “improved” receive from this article, do they? The new service implements its own version of the ‘checkUser’ service. It seems to work fine with IS 4.6 SP2 and TN 4.6 SP1 installed.

No I was commenting on the ‘built-in’ service to explain why it wasn’t working.

Sonam,
in the article you say

Additionally, a Java service to determine the IS username of the currently logged-in user is included in the package’s “utils” folder. The package “DDCommon.zip” can be downloaded from the wMUsers.com Shareware page

this service is just what I need, but I connot find DDCommon.zip on the shareware page. Can you tell me exactly how to download it

thanks

Graham

Hi, Graham.

Check the article now. Thanks to you, we have recovered a lost link.

Thanks.

Graham,

To get the current user, invoke the following:

[url=“http://localhost:5555/invoke/wm.server.query/getCurrentUser”]http://localhost:5555/invoke/wm.server.query/getCurrentUser[/url]

Substitute your URL for mine. You can also invoke this as a service in a flow:

wm.server.query:getCurrentUser

It’s handy for error trapping.

Ray