Properties

Name

Name of this feed; use something descriptive of the feed and which distinguishes it from other feeds.

Description

The description of this feed; should include the purpose and information about the expected source system and Auto Importer specification.

Processing mode

Processing state of this feed.

• Active — Incoming files are processed and records are added to the Experience Cloud.
• Inactive — Incoming files are not processed.
• Upload with pretend processing — The feed is active, but records are not added to the database. Use this to test the feed.

After Active or Pretend jobs, the processing report shows the statistics of the event

Importer traffic

Reports statistics about recent active and pretend processing activities for this feed, including successful and failed feeds over time. All times are based on the current time when the page displays — for example, "Past Day" is 24 hours before the page displayed, not everything in the previous day. This can be different from other reports that show activity from the previous day, which would be all traffic that day.

This information appears only after the feed has processed files.

Lifetime of Feed Files

Count of days to retain imported files and processing reports. After this many calendar days, the files are purged from the data centers. Default is to use the Import Deletion Schedule setting on the Company settings screen. See the description of that field for considerations about choosing a value. To be compliant with the E.U. General Data Protection Regulation (GDPR), this value should be 30 days or less.

This setting does NOT affect files retained on company-hosted or Medallia-hosted FTP/SFTP hosts.

Important: To comply with GDPR policies, files are deleted after 30 days.

Web API configuration

Record processor

Processing options

Primary UnitGroup

(Auto Importer only) Sets the From address of the report e-mails. When this property is set, the Auto-Importer does not determine the survey permission and or do duplicate checking.

(Lego only) Only accept records with Unit IDs in the selected Unit groups. Records for Units not in this Unit group scope are rejected. Applies only to LegoProcessType of SURVEY_IMPORT and SURVEY_UPDATE. It does not work for other process types such as STAY_IMPORT, EMAIL_IMPORT, or OPTOUT_IMPORT.

Extract archive

Extracts records from an archive (such as a zip file) when the content is a compressed file. This option is on by default, and this option is only available when first creating the Feed. After saving the specification the first time, this option is no longer available. In practice, there is no reason to turn this off.

Preprocessor

Only for Auto Importers. Which Auto Importer Preprocessors to use on incoming data before passing it to the Auto Importer processor.

Web Feed mode

How incoming files are processed. The processing modes are:

• Feed File (non concurrent) — Each incoming request generates a new feed file, the same as done for SFTP and Feed Pulls. Use this mode only for very low volume feeds (less than 10,000 daily requests); otherwise, the queue can grow quite large and cause processing delays or reporting instability.

  Restriction: Import API version 2 is currently available for non-concurrent processing modes. Support for concurrent modes will be added in a future release.
  Restriction: This is the only available Web Feed mode when using an Auto Importer with Lookup table processors or Org Hierarchy processors:

  • Lookup table processors cannot be used with concurrent modes. Otherwise, lookup-table updates could interfere with each other. For information, see Lookup tables.

  • Org hierarchy processors cannot be used with concurrent modes, because updating the org too many times can cause reporting instability. Consider also using grouping for this type of data import.

• Concurrent Synchronous — Use for medium volume of incoming requests (less than 100,000 daily requests) that need to be processed in parallel. The API client making the request will need to wait for each request to be processed, and the client will receive a response indicating the number of processed, duplicate and discarded records. Under some circumstances, such as during system maintenance, synchronous Web Feeds are processed asynchronously instead. As such, the external service should always be able to handle asynchronous and synchronous responses.

• Concurrent Asynchronous — Use this mode when advised for the highest volume integrations (more than 100,000 daily requests). Requests are queued for asynchronous processing, but processing occurs in near-real-time batches with some delay introduced to allow for grouping and de-duplication of requests.

  Tip: Consider activating asynchronous sampling for concurrent Web Feeds: it is not efficient to run the sampling process on small data sets on every HTTP POST request. Activate this sampling mode so that the process runs in batches of 5,000 records. For information about sampling modes, see Enabling asynchronous sampling.

Important: When switching a Web Feed from Feed File mode to one of the concurrent modes, make sure the Auto Importer is not set to capture the incoming filename in a required field. Concurrent modes do not generate a feed file, so there is no filename to capture, which leads to records being discarded due to missing required values.

This table summarizes the differences in the selection between these options:

Consideration	Feed file (asynchronous)	Concurrent synchronous	Concurrent asynchronous
Request volume	Use for low volume integrations (less than10,000 daily requests across all web feeds). Use this mode for testing to get a detailed explanation of what happened or went wrong during importer development. After testing, switch it to the appropriate mode for production use. Warning: Running large-volumes of feeds with concurrency off can impact performance due to the need to create a feed file for each request. Do not use this for testing in a production environment. In this scenario, Medallia recommends limiting web feeds to no more than 10,000 records per request. Work with the Medallia Professional Services team if you need to send a larger number of records.	Use this mode for low to medium traffic use cases, up to 100,000 daily requests across all web feeds.	Use this mode for the highest volume integrations (more than 100,000 daily requests).
Size limit	Limit to no more than 1.5 GB.	Limit to no more than: 1 request per second 100 records per request 5 concurrent requests 100 MB	Limit each API request to no more than 51.2 KB. Larger sizes can be evaluated via a Support case for a scale review.
Unit and Unit group update	Use for updating Units or Unit Groups for performance. Consider also using Seconds to wait for grouping for high-volume installations.	Does not support updating Units or Unit Groups.	Does not support updating Units or Unit Groups.
Response behavior	Response indicates the request was accepted for processing.	Response is the status of the import processing.	Response indicates the request was accepted for processing.
Obtaining process results	Response does not show processing results. Go to the Feed Files screen to obtain processing results or access version 2 API endpoints.	Response contains high-level processing results but no details.	Sends accepted response before file processing. It can process multiple requests in parallel. Parallel requests, however, are queued and processed after responding to the client side.
Email notifications	Sends notification emails per the Email Reports properties.	Sends notification emails for Failures per the Email Reports properties. For information, see Email report.	Sends notification emails for Failures per the Email Reports properties. For information, see Email report.
Grouping feature	Can use feed-file grouping to collect multiple requests into a single import process. See Seconds to wait for grouping for details.	Cannot use feed-file grouping.	Cannot use feed-file grouping.

Tip: Medallia strongly recommends the sending system enable a "retry policy" on their side in the case of a failed event.

Warning: Synchronous (concurrency on) Web-feed processing happens in real-time as the data arrive. However, there can be delays after the data is imported, depending on the load of the system. Invitations resulting from a Web Feed can be sent within seconds of arriving from the Web Feed, but in very large-volume installations, the delay can be as much as 15 minutes.

Duplicate checking in the target import specification will not catch duplicate records in concurrent or near-concurrent Web Feed imports. If there is a possibility that near-concurrent Web Feeds will have duplicate records, create Quarantines to prevent duplicate invitations.

Seconds to wait for grouping

Only for Auto Importers. How long to wait (seconds) when collecting feeds before compiling them into a single feed-file.

For Web Feeds, this option is only available for Feed-file mode.

Warning: Feed-files are always converted to CSV format in the group, regardless of the original format included in the request content. Sometimes columns/fields included in the request do not appear in the CSV files (regardless of the columnsCheck setting in Auto Importer specification). To ensure the intended fields are always included in the CSV file, reference each field with <input-column ...> in the Auto Importer specification.

Use this option for integrations that receive a high volume of requests, but where processing those requests immediately as they arrive could cause potential performance problems, such as when updating the Org Hierarchy (Unit or Unit groups).

Restriction: Grouping is mandatory for new Web Feeds using Auto Importers with Org Hierarchy processors. The recommended minimum value for this parameter is 120 seconds. Existing Web Feeds for Org Hierarchy where grouping is not active can be updated, but Experience Cloud shows a warning message instructing you to activate this feature.

Additional notes:

• Feed files grouping starts when the first feed-file arrives. For example, when the wait time is 3600 seconds (1 hour), and the first feed file arrives at 1:17 PM, and other feed files arrive at 1:20 PM, 1:36 PM, 1:52 PM; then all 4 feed files are processed at 2:17 PM. If the next file arrives at 2:20 PM, all the files for that hour are executed at 3:20 PM.
• Generally, the files are processed in the order they arrive. If two files arrive at near the same time, it is possible their order would be reversed.
• The Feed Files screen shows the grouped files after the group is processed. For a brief period of time, individual files may be shown, but eventually they are collected into the single group.
• Changing this value on a live instance affects the start of the next group; it does not change the wait time of any groups in progress.
• If there is a problem with the instance while processing a group, it is possible later files in the group are processed later than the earlier files in the same group. For example, if the instance restarts, the wait-time is reapplied to the remaining files, and they are processed when the new wait-time expires.
• Pre-processing happens as the files arrive: the pre-processed results are in the group.

• If you are using this option and change the processing mode (e.g. from pretend to active) while the current grouping is still ongoing, note that, once the grouping period completes, the grouped file will be imported with the current processing mode configured on the web feed. For example: if there is a wait time set to 3,600 seconds, and the first feed file arrives at 1:17 PM, and other feed files arrive at 1:20 PM, 1:36 PM, 1:52 PM, and you change the processing mode from pretend to active at 2:05 PM, all 4 grouped files are imported at 2:17 PM in active processing mode.

Email report

Summarized reports are available for Feed-file mode; Failure reports are available when Run concurrently is on.

Summarized report e-mails

Only for Auto Importers. Email addresses (comma-separated) to receive the summarized processing report of successes and failures.

Failure report e-mails

Email addresses (comma-separated) to receive the summarized failure report of failed concurrent imports.

This happens when there is a problem processing the Web Feed, such as a malformed or empty JSON entity; it does not happen when there is a problem processing individual records.

Post-processing options

Post-processing actions are optional activities to happen after the Auto Importer successfully updates the database. These do not happen when the importer fails to update the database, such as when a record is invalid or when a file is processed with Upload with pretend processing.

Trigger

Trigger options define when and what to trigger as part of the post-processing actions. This section appears after turning on Trigger an export after file is processed, and saving the configuration.

Debugging

The debugging option triggers the creation of feed files for the concurrent modes. This section appears after selecting any of the concurrent web feed modes, and saving the configuration.

Each feed-file is included as an entry in the Feed Files screen so it can be examined.

To avoid generating a large number of feed files (which can load on the system), the process will automatically stop after a minute.

Request/response formats for version 1

Requests sent to the Web Feed API are HTTP POST protocol. The information in the request includes:

• The request URI:
  • Always use the base instance for the company's Medallia installation (the part before medallia.com); do not try to bypass the load-balancer.
  • Must include the Username, such as https://<instance>.medallia.<com>/<company>.feed?<mywebfeedaccount>.
• There must be content: the block of data the external system is sending. The data can be text or binary.
  • The content may contain one or more records. When there are multiple records, the request is treated as a single import process, as if it was a single import file.
• There should be a Content-Type: header field describing the content. The acceptable types are
  • application/json for JSON
  • application/xml for XML
  • text/xml for XML
  • When this field is missing, the Web Feed will pass the data to the Auto Importer, which will attempt to discover the format.
  • When there is a Preprocessor specified, this field is ignored and the Auto Importer will attempt to discover the format.
    Note: Experience Cloud requires a flat, pretty-print JSON/XML structure which does not contain nested nodes. The attribute names need to match those agreed on in the data specification to ensure they can be correctly processed by Medallia.

    Below is an example with 2 rows/records:

    [
      {
        "transactionDate":"2017-06-22 17:05:00 -08:00", 
        "customerId":"CUST001", 
        "customerEmail":"john.doe@example.com"
      },
      {
        "transactionDate":"2017-06-22 20:13:00 -08:00",
        "customerId":"CUST002",
        "customerEmail":"jane.doe@example.com"
      }
    ]
    

    The following structure would not be accepted, since it contains nested nodes:

    [
      {
        "addressGroup": {
          "home": {
            "street":   "20 street name",
            "postcode": "2001"
          },
          "work": {
            "street":   "30 street name 2",
            "postcode": "3401"
         },
        }
      }
    ]
    

    Use Auto Importer Preprocessors to prepare feed-files for Auto Importer Processors by transforming the contents into a format the processor can read.

     
• An optional Accept: field tells the Web Feed how to format the response. The acceptable types are
  • application/json for JSON
  • application/xml for XML
  • text/plain for plain text; default when Accept: is missing.
• No other header fields are expected.

The Import API returns an HTTP response that includes:

• The format is
  • When in synchronous mode (concurrency on), a "Success" message matches the one specified by the Accept: field, if any.
  • Otherwise the former is in plain text.
• The response begins with the HTTP Status Code.
• The body contents depend on the status code.
  • For code 200 and when processing a feed-file (concurrency off), the content is "ok; feed file created".
  • For code 200 and when immediately processing the request body (concurrency on), the content is a report of the processing statistics, like this JSON message: {"records":1,"duplicates":0,"rejects":0}.
  • For code 202, the content is "ok; feed file created".
  • For all other codes, the content is the error message(s), such as "Import spec has not been configured".

These are the HTTP status codes Web Feed returns:

Request/response formats for version 2

Requests sent to the Import API version 2 are HTTP POST and HTTP GET protocol. The information in the request and the response includes:

The feed is often used for importing single records for creation or update in near real-time as the data change in the source external system. The request body should be encoded in a JSON array of objects, with each object containing keys and values that match the input columns of an Auto Importer configuration.

The API is asynchronous; the response is a JSON object that includes:

Query processing status via an HTTP GET request. Use the feed_file_id parameter to ping the status endpoint to understand if the ingestion job is queued, processing, or complete. The response is a JSON object that includes:

Once a feed file has completed processing (status = COMPLETED_RESULTS_READY), the results of that job are available to query. For each record in the feed file, the API response will show the result of the record whether it was successfully ingested or if the record was discarded and what was the error reason. The response is a JSON object that includes: