Protocol Options

How Do Vendors Connect with the NoodleBus and IDataHub?

Connecting with Student information (ERP) systems:

The NoodleBus includes direct, secure, and real-time connections to the major higher education ERP systems.

 

Connecting with other point solutions:

For other vendors, the Noodle bus has three main options for connectivity:

  1. Open standards that use inbound and outbound restful web services (JSON)
  2. Open Standards that use inbound and outbound flat-file exchange.
  3. If a vendor is unable to communicate with the standard web-services or flat-file formats, then there is an option to build a custom connector in the IDataHub that will communicate with the vendor’s existing API formats.

 

Note: Whenever possible, the preference is to use web-services in order to take advantage of the more robust transaction status handling and real-time processing.   The custom option is not the preferred method and may require contracted services for development and ongoing support and maintenance.

 

Flexible Protocol Options for the Same Functionality

A powerful feature of the NoodleBus is that the standard supports multiple protocol options.   The functionality of posting prospect data, for instance, to the Noodle Bus is primarily about loading the data objects and fields for that prospect in to the NoodleBus Core, so it can be routed to the appropriate target systems.   The method or protocol used to post the objects can be flexible if the objects and fields are mapped in to the same standard data model in the Noodle Bus core.  This allows systems that are connecting to the NoodleBus to use a protocol that works best with their architecture.   This includes web service options, flat-file options, or a custom connector.

 

 

Web Service or CSV protocol options:

The standard API’s for connections with the NoodleBus supports both web-service (JSON) options and flat-file (CSV) Options.  Both methods include the same data payloads with the same field naming convention. Both methods support the sending multiple records in a single transaction (i.e. a batch of records). Both methods also support the inclusion of multiple “Objects” for each record (i.e. person, address, application, test scores, etc.). There may be a many-to-one relationship for some objects to the primary record (such as multiple address items for each person).

 

Web Service Options:

The NoodleBus includes a listener for inbound Web service requests.

  • Web Service Posts to Noodle Bus – Vendors can make JSON web service posts to the standard API’s that can include one or multiple records in a batch. The NoodleBus will respond to the post with transaction statuses for the Batch, each Item, and each Object. The posts may be routed to multiple target data agents.  The Noodle Bus will track and respond with transaction data for each target data agent.
  • Web Service Get requests – the Standard APIs support the ability to submit a Get requests from a vendor to the Noodle Bus.   Each Get has a set of filtering parameters.  These get requests, by default are designed to return a batch of new and changed items.  Since the NoodleBus cannot always rely on all connected source data agents having real-time capabilities (i.e. a connected CRM may only support scheduled flat-file extracts.), the standard API’s will not always support pure restful gets for individual data records.  For more information, refer to the each API’s specific on-line documentation.
  • Web Service Post from the NoodleBus – The Noodle Bus can initiate and submit a web service post to a vendor. This requires that vendor enable a listener to receive the post and ingest or translate the data.  The vendor will need to respond with the standard transaction statuses (at least the Batch status, item and object statuses are optional.  Note: The data payload in the outbound web services post contains the same data as the outbound CSV option (see below), however, the CSV option has no direct capacity for a synchronous response with an item status or other response data (such as ID exchange).

 

Flat-file (CSV) Options:

  • Flat-File CSV Post to the Noodle Bus – The Noodle Bus uses a scheduled directory sweeping approach to pick up single or multiple CSV flat-files in a Comma/Quote-delimited format. The CSV contains the data payload for one or many records. The IDataHub can be configured to pull data from any local or external directory with available access (using a secure file transfer for non-local directories; sftp and Amazon S3 are both supported).
  • Push of a Flat-File CSV post from the Noodle Bus to a vendor – The NoodleBus can be scheduled as frequently as needed in the IDataHub to push files to any local or remote directory using a secure file transfer protocol.

 

  • Transaction Status Posts or Request Web Service – If the vendor is using the flat-file protocol method, the NoodleBus includes the option to make an asynchronous web service Post or Get to update the transaction statuses for a completed batch. These transactions need to include the NoodleBus Batch ID. <note:  This is a roadmap feature not yet available>