Print this page Print NPIF » NANC Change Orders » NANC 349

NANC 349

Batch File Processing

Origination Date :03/06/2002

Originator:Neustar

Description:

Business Need:

Service Providers periodically generate large porting activity.  The current definition includes ports with 500 or more TNs.

The NPAC receives these large port requests via an online mechanism (CMIP interface or LTI), and processes them at that point in time.  The current requirements do not allow for “off-line” processing of activity.

As an alternative to generating all the messages associated with large porting activity, and sending them across a Service Provider’s CMIP interface, a batch mode can be implemented whereby a Service Provider can send a batch request to the NPAC, and request that it be processed after a certain date and time.

With this change order, the NPAC and the Service Provider can offload processing that can be worked separately, but still meet the need to incorporate that work after a specified date and time.  Since all large porting activity is known well in advance, both planning and processing can be addressed, thereby benefiting risk management.

The functionality covered in this change order could be any activity that is not time critical and typically done over a 24 hour period (e.g., pooled blocks where not time sensitive, or an LSMS for DPC codes).

Final Resolution:

Interface and Functional Backwards Compatible:  YES

The NPAC would incorporate an offline batch processing engine that handles batch requests from a requesting Service Provider.  The Service Provider would place the request in their ftp site directory.  The NPAC would periodically scan for requests, pick them up, and process them offline.

After reaching the Service Provider’s requested date and time, the request would become “active” and the NPAC would process this request during off hours (e.g., during nightly housekeeping).  Upon completion, the requested activity would be incorporated into the production database. Updates or notifications could be either placed in a response file at the Service Provider’s ftp site directory, or sent across the interface to the Service Provider.

A new indicator would be added to the customer profile record.  This would indicate whether the Service Provider supports batch processing.  If yes, any batch requests would be responded back to the Service Provider in batch mode, via a “processing done, here are the details”  response file (placed in the ftp site directory).  If the Service Provider does not support batch processing, the NPAC would send the responses to the requested activity over the interface.

Jul ’03 APT:  The intention is to off load the interface and have it done at off peak times.  The benefit is to move large volume transactions off the CMIP interface.  SPs need to categorize the real-world scenarios, and provide feedback on this change order.

Aug ’03 APT:  Real-world scenario - bulk port over 500K numbers.  Business need to move numbers off the switch.

This change order will be prioritized behind the other SOA requirements.  So, move out of APT document and back into main change mgmt list.

Oct ’03 APT:  Since this relates to performance, it belongs in the list of change orders worked by the Architecture Team.  Refer to the latest APT Working Document for additional details on this change order.

Major points/processing flow/high-level requirements:

  1. NPAC messaging with SOA/LSMSs operates in a real-time mode.  In some non-time-critical functions, a batch mode could meet the business need.
  2. Using this alternative interface mechanism (i.e., batch mode), traffic will be offloaded from the CMIP interface:
    • A Service Provider can send a batch request to the NPAC, and request that it be processed after a certain date and time.
    • A Service Provider can utilize FTP mechanism to transfer the to/from the NPAC on a when-convenient basis.
  3. The functionality would be set up to provide notifications in either a batch file, or sent across the interface.  A Service Provider tunable would be established to indicate one or the other.Batch File Processing Functionality – NPAC SMS shall provide functionality that allows batch file processing of Service Provider SOA SV activities.

Requirements:

  1. Batch File Processing Format – NPAC SMS shall use a defined batch file format to batch process Service Provider SOA SV activities.  See Appendix (TBD).
  2. Batch File Processing FTP Sub-Directory – NPAC SMS shall use the FTP sub-directory of the Service Provider, based on the SPID value of the requesting Service Provider in the Batch File.
  3. Batch File Processing SOA Batch Notification Indicator – NPAC SMS shall provide a Service Provider SOA Batch Notification Indicator tunable parameter which defines whether a SOA supports receiving notifications for batch requests in file format.
  4. Batch File Processing SOA Batch Notification Indicator Default – NPAC SMS shall default the Service Provider SOA Batch Notification Indicator tunable parameter to TRUE.
  5. Batch File Processing SOA Batch Notification Indicator Modification – NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider SOA Batch Notification Indicator tunable parameter.

Dec 05 – Moved to Cancel-Pending per LNPAWG discussion.

3/06 – Deleted after March LNPA WG meeting.

Related Release:

N/A

Status: Closed