Remote tables
-
- UpdatedAug 1, 2024
- 5 minutes to read
- Xanadu
- Remote Tables
Connect the Now Platform to third-party sources, or to another instance, so that you can retrieve external data and optionally cache it in memory. You can view external data in lists or forms and process it with standard Glide scripts. You can also group, sort, aggregate, and filter the data just like you would for standard internal tables.
Remote table components
- Remote tables
- You create remote tables to describe the schema for the data that you want to retrieve from an external source.
The table definition is in the Now Platform, but its rows, or external records, live in memory. You create a remote table the same way that you would create a standard internal table. You define columns and controls and designate application access for it just like you would do for an internal table. Unlike an internal table, a remote table does not get its records from the Now Platform database. It gets its records from running an associated script against an external data source.
To learn more about creating remote tables, see Create a remote table.
- Script definitions
- You create and associate a script definition with a remote table. The external data that you've retrieved using the script can be cached in memory. You can also designate how this data is cached and how long the data
is cached in memory. Every time that you refresh a list that contains the external data from a remote table, the associated script runs again.
To learn more about script definitions and how to associate them with a remote table, see Create a script definition for a remote table.
How remote tables work
By using a remote table, you can retrieve the data from external sources or from another instance with REST or SOAP services. The external data lives in memory in read-only mode, which makes the data temporary, or transient, within the Now Platform. You can then view and manipulate the external data without importing or storing it.
You view the external data in lists or forms in the same way that you view internally stored data. You can manipulate this data by using standard Glide records, business rules, remote APIs, scripting, table reference fields, services, and development tools in the Now Platform.
External data life cycle within the Now Platform
- When you run a script that is associated with a remote table, the retrieved data lives in memory for as long as the list or form appears. After you close the list or form, that external data is purged from memory. The next time that you use or view the external data in this remote table, memory is repopulated from the external system.
- However, if you have defined caching parameters for the script, the external data remains cached in memory for the specified caching duration.
For example, if you designate that the external data should be cached for 300 seconds, it remains cached in memory for 5 minutes. After that time expires, the cached data is purged from memory. The next time that you use or view the external data in this remote table, the cache is refreshed from the external system.
Practical applications for remote tables
Set up and use remote tables in your enterprise when:
- You want to fetch external data for temporary use without storing it in the Now Platform. For example, you can create a remote table that fetches weather-related data that appears on a homepage when a user logs in. You would then create an associated script definition that retrieves this data from a third-party weather source that is based on the user's location.
- You want to retrieve customer details that are stored in an external Customer
Relationship Management (CRM) application for viewing in Customer Service Management functions
such as Agent Workspace. Note: To learn more about data retrieval for Customer Service Management, see Third-party data integration for CSM.
- You want to retrieve and view personnel data from Human Capital Management (HCM) applications such as Workday or SAP SuccessFactors for use in HR Service Delivery functions.
Post-filtering and sorting
When you run a remote table script, it applies post-filtering and sorting query conditions after it adds rows to a table. These applied conditions support any other required queries that the script does not handle. When you apply post-filtering and sorting, the remote table queries work like standard internal table queries.
When you create remote table scripts, you generally handle the most frequent and expansive queries in the script. Post-filtering queries and sorting can take a long time and may adversely affect how your instance performs. Use a small data set instead so that it doesn't take much time to do post-filtering and sorting.
Based on your use cases, determine if you should try a narrower query in the external call or a more expansive query. Because the internal filtering and sorting can be expensive to run on large result sets, use a narrower query when the data doesn't require extra filtering. Use a more expansive query when a more general query would return a small result set and would require extra filtering and sorting.
Differences between remote tables and the Integration Hub
- When you want to temporarily cache external data, use remote tables.
- If you want more advanced importing and transformation options, including Workflow Studio, or if you want to develop custom integrations, use the Integration Hub.