We're in the process of moving our Tessy environment to new servers (Windows 2012 r2 paired with SQL Server 2014). In our existing environment the payment gateway service lives on its own server. Having since moved away from Transcend, we no longer require this particular server...so we're hoping to consolidate. In our environment this basically means either our REST/SOAP gateway server (or) tessitura db server.
I have asked Tessitura in the past if either location is more ideal and was told that either is fine so long as you have the resources. Though we do have ample scalable resources (virtual servers) and I like the idea of housing the pmt gateway on our rest/soap server overall, high on sale situations have potential to really slam the API...which leads me to believe that the database server may be a better location overall.
I plan on doing stress testing once all systems are configured, but am hoping to make a good informed decision before getting to that point.
All that said, I'm curious what ya'll's setup is like (and why)?
Thanks!
Does anyone know if Tessitura supports multiple payment gateways? If so I'm curious if anyone is running with multiple instances. If it does, one configuration option that I've been considering is housing a payment gateway on our internal-facing rest/soap server, and another on our external-facing rest/soap server. So effectively one gateway takes care of web transactions, the other client app transactions.
Tessitura does support multiple payment gateways. Several sites have done this by adding an additional CCSERVER_IP_ADDRESS and/or CCSERVER_PORT to T_DEFAULTS with a different TR_ORGANIZATION. This is the only way to configure which users connect to which Tessitura Payment Gateway service. Jason, in your case this would work because if you are separating web transactions, you could most likely add these rows using "Tessitura Web" as the parent table.
Some sites have done this because they wanted different processors for different TR_ORGANIZATIONS (such as org A on Element and org B on TranScend) but you could certainly keep the same configuration as well.
For sites that are freeing up a server/VM by moving away from TranScend and are considering where to host the Payment Gateway -- the database server is such a critical resource that I prefer not to host other components on that server/VM. I've seen situations where Tessitura components or other software have starved Microsoft SQL Server of critical resources (mostly RAM). There are also concerns with PCI-DSS v3.0 item 1.3.7 (PA-DSS v3.0 item 9.1) -- once you have a component where you are doing internet access from your database server, you have to be more careful. I believe the rules are mostly concerned with having a web server not be on the same server/vm as the database server, but I mention this because different auditors have different interpretations.
I really like the idea of breaking apart our web (external) and client (internal) transactions. If we did the tr_organization setup as mentioned (creating entries for Tessitura Web), is it as simple as that? (Ie does REST/SOAP services automatically start using the alternate payment gateway addresses, or does there need to be additional configuration on the REST/SOAP servers?)
This may have swayed me to get the gateway off of the DB server. I'll still stress test both scenarios (db vs rest/soap server) to see what the differences are in terms of resource utilization and throughput (checkouts)...just out of curiosity.
One more question: does the seat server support multiple servers as well? Could be interesting to do a similar setup with that...