I’ve written a custom immediate delivery service. It worked fine in my development environment, with one exception: it was being called remotely even though it was local. This was failing because the TN client apparently didn’t authenticate, so the call to the service failed with an authentication required exception. To get around this, I set the ACL on the immediate delivery service to Anonymous. The problem stopped and the service worked fine.
I’ve now moved it to our STAGING environment. This is on the same server but a different port (6666). When I attempt delivery now, it is doing a remote call back to my DEVELOPMENT instance. I went back to my DEVELOPMENT instance and set the ACL on the service back to default. Then I went back to my STAGING instance and reprocessed, and sure enough it failed with that authentication problem (that would only happen if it were trying to call into the development instance).
When I get the info about the registered service, there is a value of “local” that is “true”. And there is no remote information associated with the registration.
I’m on 8.2.0.
Any help would be appreciated ASAP! (I also put a ticket in with SAG)
I filled in the connection information in the delivery setting on the trading partner profile (with my user ID and password).
That got around these problems. I’m still mystified, though, as to why the default behavior doesn’t work in such a way as to just make the call local without requiring re-authentication. I feel like I’m still doing something wrong or there’s some magic knowledge that would make this easier to maintain or more straightforward.
Yes. I can indeed get it to work in the staging environment. However, this feels unnecessary and unfinished to me.
I’ve tried setting the host/port/user/password in the registration per the documentation. That seemed to have no effect whatsoever. The only thing that seems to work is entering these values on the trading partner profile.
It seems like this is not working like the documentation suggests or like one might expect. For instance, the documentation says that this information on the screen is ignored unless you’re using one of the standard delivery services. Clearly it is not only not ignored, it is absolutely required for correct operation.
Yes not always documentation is straight forward and you can basically see how the built in delivery services work and the same way it has to be the service inputs for the registered service flow should be.
For those of you interested in this thread, it turned out that this was corrected by a fix. I have applied the fix. I can’t speak for whether it is completely correct, because it appears to have stopped trying to call the delivery service remotely (which makes sense, since it is a local service). Therefore, it appears to not even need to authenticate anymore. Just avoiding the whole authentication thing fixes it for me.
Per the documentation in the fix, it appears that they have corrected the whole thing to work as documented.
