Request and reply
Usage: The request and reply pattern utilizes the HTTP protocol to transfer data to Service Objects Web Services where the data is processed, validated and/or appended to and returned to the client.
Example: A custom web form which captures a user’s contact information to be inserted into a CRM or database. In this example, a developer would integrate a POST call to Service Objects on form submission to validate the user’s contact fields prior to inserting data into a CRM or database.
Best Practices:
Timeouts: Whether integrating Service Objects Web Services in an application or web page, implementing the correct client timeout setting is vital to the function service. If the timeout is too long, application performance or user experience can be degraded. Conversely, setting the timeout too short will not provide the service with proper time to perform its function and return a result over the network. A general rule of thumb for client side timeout settings is around 3 seconds for most of Service Objects Web Services. However, there are some services which potentially require a longer timeout due to the nature of work being performed. We always recommend consulting with Service Objects Support to get the best-recommended settings for the service being integrated.
Failover: Having redundancy available to our clients is vital for mission critical systems which cannot afford downtime or lack the ability to process incoming information. Service Objects offers multiple redundant datacenters to meet the demands of these systems. We encourage our clients to make use of these locations in their integration logic in the event of a slowdown or issue at one of our datacenters. Coupling failover integration with proper timeout settings provides a reliable system which ensures zero downtime in critical systems.
HTTPS:
Security is an equally important consideration when transmitting user information over the net.Service Objects strongly recommends transmitting all calls be made using https. This ensures all client information including license key are encrypted during transport.
Remote call in
Usage: The remote call in pattern utilizes the HTTP protocol for Service Objects to make requests to remote applications for available records to be processed. If available, these records are exported for processing and upserted into the remote application.
Example: A Salesforce application which flags incoming leads to be processed by Service Objects. Service Objects would act on the client’s behalf and periodically check for contacts that are available to be processed. If contacts are marked as available to process, Service Objects would bulk export contacts to process and reinsert into the system as a post processing step.
Best Practices:
Credentials: When acting on the client’s behalf to process records, we always recommend creating a user account with API level credentials which is easily identifiable. This prevents access from being inadvertently revoked by system administrators which can cause issues in application workflow.
FTP batch upload
Usage: Service Objects provides an SFTP user account to the client for batch uploads to be processed and returned. With each batch file that is processed, a report is included in the package returned to the client with metrics on the data that was processed.
Example: Client X joins into agreement with Service Objects to batch process records. Service Objects provides whitelisting to the client’s IP for access to the SFTP account. On demand, a batch file is securely transmitted via SFTP protocol to Service Objects for processing. Each data file is preprocessed to ensure field mappings are adhered to and records are ready to be processed. Once completed, the processed files are packaged along with a metrics report for Client X to retrieve.
Best Practices:
File Format: Service Objects regularly accepts multiple file formats, however it is recommended that all files delivered for processing be encoded in standard utf-8 character encoding with Windows line ending format.
Header Format: In the setup process, Service Objects will receive a sample file for processing from an FTP client. It is recommended to provide a header line along with the data to be processed for simplified identification of fields to be processed. It is not uncommon to receive input files with more than 50 fields which can make identification of input fields more difficult without a header line. We also recommend simplified location of input fields within the input file. If the input file will have fields other than the input fields, the input fields should be grouped together towards the left side of the document if possible.
Column Format: Service Objects recommends that columns should be quote enclosed to ensure that all files are valid CSV. In some cases, address information can break CSV files which can halt processing to fix any necessary columns.
