Best Practices

Here are our recommendations for various actions within SymXchange.

SymXchange Startup Time

• You may be able to improve startup time for SymXchange by using XmlSerializer. You can find more information about XmlSerializer and its benefits here.

SymXchange Services

• Do not enable all service versions for all SymXchange instances. This helps conserve memory.
• Although SymXchange supports four service versions, we recommend you use the latest version for optimal performance.
• If you enable BatchService and ContactEventMgmtService without fully provisioning them, SymXchange will not start. You must fully provision these services if you enable them.

SymXchange Operations

• Use more targeted calls to scrape the database (DB) hierarchy. Do not use SymXchange for the entire DB hierarchy.
• Be aware that the number of fields retrieved for a record impacts performance. When you perform a request that retrieves all fields for a record (e.g., getAccount), or set IncludeAllFields to a value of True in requests such as getAccountSelectFieldsFilterChildren, this can cause performance issues. When these requests are used in high-volume applications, especially when applied to responses with lists of records, the impact is multiplied by the number of records and can be significant.
• When you search or filter in SymXchange, SymXchange looks for matching records until the maximum response size (measured in by number or records) has been met or all records have read. This is unlikely to be a performance concern in the case of normal records, as there are unlikely to be a large number of records. In cases concerning transaction or FM history, there may be a very large number of records and understanding the behavior becomes more important.
• When you search for a transaction with a specific date range or transaction amount, the search continues processing until the maximum number of records for the response have been found or the end of the records is reached. This will perform poorly if the number of matching records is low and the number of overall records is high. The maximum number of records can be adjusted in the Maximum Search Response List Count setting for the SymXchange instance. The default value is 1000. The setting is accessible via Web Console.
• If you place a transaction search into a separate request, an operation that supports paging can be used, such as searchShareTransactionPagedSelectFields. These operations allow “paging” through the records by an amount set in the request. Once an entire “page” is filled, if there are more records to be read, the response will include a token that can be used to resume reading at the next record.
• If your goal is to retrieve the transactions based on date, especially the transactions for the last week or month, we recommend using the standard paged operation without search.
  • Example: getShareTransactionPagedListSelectFields rather than searchShareTransactionSelectFields/searchShareTransactionPagedSelectFields
  • The transactions are returned in the reverse order that they were posted, newest to oldest, and this avoids searching all transactions. The best performance will be achieved by setting the page size such that a single request is sufficient. Multiple pages can be requested for unusually large responses.
• For a date range, using the starting date without the end date will ensure that enough records are found to fill the page. If the end date is used and the number of records in the date range is less than a single page, then the search will continue to look through the records to find matches in order to fill the page.
• If the request is expected to have a single match, such as a check number or a date and sequence number, set the page size to one to avoid attempting to read additional records.
• Searching for newer records will be faster than older records due to the way they are ordered.
• Some searches will need to read all records and these may be slower due to the number of records being searched. Performance in these cases depends on the transaction activity for the share or loan and how often transactions are purged from the system.
• Using user credentials with advanced hashing can cause performance issues. If user credentials are needed, we recommend using the UserManagement service to get a token, and then using the token credentials.
• When performing a withdrawal from a share to a GL using a GL code, you can use the withdraw call in the Transactions service. Within the call, there are sections to specify a whole GL account number or a GL code for the other half of the withdrawal transaction.
  • While deposit transactions default to cash, withdrawal transactions default to the amount being disbursed by check and therefore, will use the Chk Disb GL code, rather than the Clearing GL code.
  • For withdraw calls, you need to use a user-defined GL code by using the CheckDisbursedCode field. For deposit calls, you can use the ClearingCode field.
• The UserService WSDL allows the Admin Password credential parameters to be used. Currently, User Number credentials are not supported. If you attempt to retrieve or update User record information, you receive the following message: This user does not have the required privilege.
  • Additional security privileges and controls to allow greater functionality will appear in a future release.