Entity Processing Information and Usage Notes

  • API processing is not a substitute for high-volume batch file processing. To process large quantities of data, use standard TIBCO Reward batch processing methods. Batch file processing also performs many data validation functions. For details, see the TIBCO Reward Integration Guide.
  • Unless stated otherwise, attributes have the same meaning as fields in batch files with the same names, as these fields are defined in the TIBCO Reward Integration Guide.
  • API processing includes no data validation.
  • If clients want to validate data, they must implement local data checking edits and processing.
  • Email address validation is not enforced through APIs, so the API can create a shopper with an invalid email address. If not caught and corrected, this would be an unserviceable customer record.
  • API processing physically allows you to insert null values, even where these can cause problems. The tables provided in this chapter indicate which fields must not be nulled.
  • TIBCO Reward's API uses generic error-handling messages to pass back exceptions for web service calls.
  • If the TIBCO Reward system is unavailable because of network problems (at the client, at TIBCO Reward, or at any third party server/service) or because the TIBCO Reward system is down, no data transmitted via API can be processed or queued by TIBCO Reward. You, the client, should implement a loosely coupled queuing system in case such problems occur. If you are not familiar with the errors you might receive, see this article: http://ws.apache.org/axis/java/client-side-axis.html. It includes a section on troubleshooting network problems and what errors you might receive.
  • Clients must handle SOAP exceptions. For examples, see the samples provided in Preparing to use the API.
  • API methods for adding new shoppers must be used only to add new shoppers and not to update existing customers. Before you use any of the APIs to create shoppers, you must verify that a record does not already exist for this shopper.
  • The Create and Score Shopper method illustrates some of the implications of these very basic rules:
    • The Create and Score shopper API will only work for new shoppers.
    • Clients must check whether the customer exists before calling this API.
    • If the customer does not exist, this API creates a new shopper and scores the shopper as eligible for offers.
    • If the customer does exist, this API does not fail. It returns the shopper data, and updates the create date, based on the date passed. However, it does not score the shopper, nor does it enroll the shopper as a loyalty program member.
    • If the customer exists, and you want to score the customer, then you must call the Add Shopper to Program API to enroll the customer. Overnight, the newly enrolled shopper will be scored.
  • Email addresses must be unique, and can be used as unique customer identifiers. If a client uses the email address as its unique customer identifier, then it cannot create a new customer record that has the same email address as an existing record in the database. An attempt to create such a new record will fail. However, if another customer ID (other than email address) is used, the API method cannot assume that the other ID is unique within the system, and the API will create a new record.