Author: Eric Vasbinder
When customers develop custom-built applications that integrate to Vista, often times those integrations make use of SQL Linked Server Objects on the local Vista database server. In addition, many third-party commercial applications that integrate to Vista often make use of SQL Linked Server Objects stored on the Vista DB server itself.
When moving to the cloud, customers will find that their ability to use SQL Linked server objects in our cloud is heavily restricted. There are a number of compliance and security considerations around this approach. In addition, our future goals to modernize Vista's backend infrastructure, including its database set up, will likely not be compatible with the use of SQL linked server objects stored on the Vista server itself. For example, if we were to, at some point in the future, make use of Microsoft's Azure SQL for our ERP solutions, Linked server objects on the database itself would no longer be possible.
To that end, nearly all use of SQL linked server objects on the Vista server itself in our cloud are not permitted. Only if an extremely stringent series of requirements are met, may SQL linked server objects be approved for installation on the Vista server in our cloud.
Please see below for our recommended approaches to use in priority order:
A powerful capability, brought to the fore by Trimble's acquisition of Ryvit, is to use the fully supported REST APIs that are exposed by our new AppXchange / DataXchange tools. As such, we highly recommend rewriting third-party applications wherever possible to utilize these REST APIs to read and write information in a scalable, future proof manner to the Vista or spectrum databases. Here are two Vista Cloud FAQ articles that will provide more details on this topic:
If it is impossible to utilize the ERP's REST APIs, provided by AppXchange / DataXchange, then evaluating the use of remotely hosted SQL linked server objects, stored on the remote server, pointing over the IPSEC VPN or TLS Endpoint to the ERP server's database, is a highly recommended alternative. In some cases, this will be fairly straightforward. However, in other cases this may be a complex endeavor. As such, please review the following two options as well.
Another option that we have seen be effective in a number of cases is where the customer sets up a sequel Jump Host server with a copy of SQL server installed upon it. The SQL Linked Server Objects are stored in this Jump Host server. In addition, this Jump Host will also contain replicated views from the ERP database. These replicated views are pointers, set up using database synonyms, which will in turn point over the IPSEC VPN or the TLS Endpoint to the ERP database. A significant benefit to this is that the SQL Jump Host box is a full-fledged member of the customers local Active Directory, or other authorizations came that is familiar to and used regularly by the customer, such as LDAP. Another meaningful benefit to this is that the linked server objects are able to reference the replicated views on the local SQL Jump Host, for all major purposes, as if those linked server objects were still installed on the Vista server itself. Finally, if needed, the third-party application itself can also be installed upon the SQL Jump Host.
Overall, this set up may provide customers with a way to move into the Trimble ERP cloud solutions with a more moderate effort to adjust their third-party applications, versus a more substantial rewrite as incurred if adopting one of the first two options listed.
In the event that none of the options listed above are tenable, it is possible, in very limited circumstances, to provide approval to utilize SQL Linked Server Objects on the ERP database directly. However, the requirements and disadvantages of this approach are pronounced:
Time Limited: Any request to host linked server objects on the ERP database must be limited to a small window of time during which the third-party application will be rewritten to utilize one of the aforesaid three previous options.
In your exception approval request please annotate in the request the specific timeframe for hosting the Linked Server Object on the ERP database. Please try to keep that timeframe to as small of a window as possible to support your efforts to rewrite that integration.
Please note, in the event that our architecture direction requires the deprecation of this option during the time of your exception window, we will make every effort to notify you as soon as possible.
Approval from Cloud Product Management: Any request to host a SQL Linked Server Object on one of our ERP cloud databases must be accompanied by an approval from the cloud product management team.
Approval from Cloud Engineering: Any request to host a SQL Link Server Object on one of our ERP cloud databases must also be accompanied by an approval from the cloud engineering team.
Acceptance of Future Deprecation: At some point in the future, changing technologies within the ERP databases themselves will make it impossible for SQL Linked Server Objects to be hosted directly within our cloud ERP databases themselves. A request for an exception to this restriction on SQL Linked Server Objects must be accompanied by an acceptance and awareness that Trimble's ability to host these objects in our cloud directly will at some point be deprecated, and then be removed. As this will be caused by possible future architectural changes to the ERP database at some point, this change in our ability to support Linked Server Objects will be unavoidable.
Please fill out the following Google form in order to request approval to host SQL Linked server objects within our cloud environment.
Remember, if you are contemplating options A, B, or C, as listed above, there is no need to fill out this form.
This form is only necessary if you are planning to utilize option D and need an approval request to host the SQL Linked Server Objects in our cloud directly.
SQL Linked Server Object Cloud Hosting Exception Request form: https://forms.gle/ko6j2rvxuZvSRE9D8
changelog
Wednesday, 04 September 2024 at 09:46PM:
Initial Posting