Additional points to note

Owned by James Seabrook
Last updated: Sept 07, 2023 by Sara Aslam

  • We use nvarchar in both SEKO 360 and iHub. It supports both Unicode and non-Unicode characters such as Japanese, Korean, and Chinese and more.

  • Carriers such as Omni Parcel support English Characters only, so the ASCII character set should be used.
  • Sales Orders created in SEKO 360 will not generate a Push Dispatch Confirmation message unless specifically requested.
  • If you use any leading zeroes in the data you provide, then this needs to be in quotes. For example, "SalesOrderNumber": "000000011".
  • Specifying a " in the text of a JSON file will cause an error.
  • For Push CSV messages, if the file contains the delimiter in the text, the text will automatically be put into quotation marks (").
  • All HUB push messages use UTC - Coordinated Universal Time.
  • Fields that reference 'placeholder': a field has been created within the message and maybe also the database with future use/functionality in mind.
  • The Push scheduler runs every approx. 15 minutes.
  • If there is nothing to push for a service within a scheduler cycle, nothing will be sent (no blank file).

  • The iHub shows the first error that in finds on an upload. Once you fix this error and re-attempt the upload, it may fail again for another reason.

  • No address validation within the Hub. 
  • We push to the endpoint 500 at a time.
  • Push files from different DC's are not combined, Push GRN, Push Dispatch Confirmation  etc. For example, two Push Stock Overnight Summaries generated by different DC's within the same time zone would send as two separate messages/files. 
  • To make it easier to spot errors and speed up the processing time, please split uploads (i.e. a product master file) into a maximum of 10k per batch.

  • Push message processing has its own retry mechanism. If a message is not delivered to a client (via FTP or REST), iHub retries to deliver the message (file or request) 3 times every 15 minutes. If after the third attempt the message cannot be delivered, iHub will no longer attempt to push the message. However iHub does support the feature of resending a push message at anytime from the Activity report. This is useful if a customer’s endpoint or FTP Server is down for an extended period of time. If iHub gets back a “400 Bad Request” response, then iHub will not use retry policy.  The retry mechanism only works for transport (i.e. when the endpoint is not reachable) and internal iHub exceptions.

  • Uploading an order for different DC codes into one CSV file is accepted. So for example an order for DC1 and an order for DC2 can be in the same CSV file.
  • Multiple entities can be uploaded in a single CSV file (i.e. multiple sales order numbers in a Load Sales Order file)
  • A Push service message will contain <Responses> tags as default no matter is one entity is included (i.e. dispatch EACH), or multiple.
  • A Load Service FTP response message will contain <Responses> tags as default only when multiple entities are uploaded in the same XML. A single entity upload will not include <Responses> tags in the response message.

Supported iHub date formats

CSV: Any format can be mapped. Must be defined during the CSV mapping process.

Other (i.e. API):  yyyy-MM-dd, yyyy-MM-ddT00:00:00.001Z


Push mapping (API and FTP)

During integration push API and FTP mapping, features include:

  • Adding placeholder fields with a static value
  • Renaming fields
  • Reordering fields
  • Ignoring fields
  • Change field type