Use of Namespace URL within Production API submissions

Scott Judd

An existing customer of mine attempted to go live with a new API application this weekend, sending simple outbound fax.  They pre-tested in PT system with no issues.  They also tested with no issues from a local machine on their end to Production on our end, again without issues after they retrieved our security cert via the browser and imported it. 

However, when it came time to send from their Prod system to our Prod system, they had issues, even after their Network team cleared a firewall route to the Production and Backup IPs associated with our Production API URL, and performed the required cert import. 

Upon further research, it appears they are also reaching to 137.236.223.106  (which is our namespace url premconn.premiereconnect.com within their submissions, "to validate for the xml schema".  Given that they have not cleared a firewall route to this IP/URL, they are getting access denied internally. 

 Customer asked if we had any issues with them opening a firewall route to this IP, and we told them "NO" if that is the immediate solution to their problem, given that this is a public, internet-facing IP/URL.

However, looking long-term, I wonder:  Is it customary or recommended for client applications to do this within the context of every job submission? 

I seem to recall a past thread or discussion indicating that our schemas shoudl be downloaded and imported into the client application ahead of time, such that repeated access to the namespace url will not be necessary in the context of production traffic. Please let me know your thoughts at your earliest convenience, and I will share this post with my client. 

Thank you,

Scott

 

skamens

You are correct - the customer's production application should absolutely not be reaching out to any namespace URL at runtime.

They should download the schema once and keep it locally.  Having the check in there is a major efficiency issue (why have to go get the schema for every single call), and it also severely limits our ability to have control over those namespace URL's in the future.

We don't really intend to make the current namespace links go away, but eventually it would be nice to do that, and if customers are accessing them in production, we wouldn't be able to do so.