Importing credit card data: upload_cc_feed.bat/sh

Functionality

The Credit Card Upload tool provides Infor cloud customers the ability to upload and import their credit card feeds . Only the start process has changed when compared to the earlier process, Credit Card Upload builds on the foundation of XMDBTool. The same ZIP file, jars, and configuration file is used.

The Credit Card Upload tool provides these features:

  • Users can upload and import Credit Card feeds in any format accepted by the Expense Management system.
  • A log file that details any errors, warnings and informational messages.
  • Transactions are available to Expense Management users immediately after import.
  • Role-based security allows only authorized users to run the tool.
  • HTTPS protocol can be specified for communication link.
  • File transfers are validated using checksums to enforce data integrity.
  • Users can retrieve just the log file of a CC import.
  • Based on the configuration setting, the overwrite flag prevents or allows overwriting of the feed file on the server.
Note: Authorized users should be assigned the XMDBTool Access role or should have the Super Admin privileges to use the tool.

On the client side, when a feed file is processed, the server returns the CC import log file. The log file is written with a .log extension and uses the same filename and folder of the feed file.

Run the batch file from the bin directory using upload_cc_feed<format><feed file> [<username> [<password>] syntax.

For example, upload_cc_feed Visa D:\visa\feed.txt admin admin

The format and feed file are mandatory. These are the supported credit card formats:

  • Amex1080
  • Amex1025
  • Amex1205
  • Amex1205GL
  • Amex1080
  • AmexGL1076-PCard
  • AmexGL
  • EuroCardXML
  • GhostCard
  • MasterCard
  • OFX
  • Visa

The login username and password can be specified on the command line or in the Properties file, with the command line values taking precedence. Other optional parameters must be specified in the Properties file.

Caution: 
  • If a CC Upload request is started before an earlier request is completed, the request is blocked. This is done to avoid duplication.
  • If any customer needs to be restricted from using the upload_cc_feed.bat file, then the value of the xm.isTokenized application parameter must be set to false in the alwf_appl_parameters table. By default, the value of this parameter is set to true.

Configuration Parameters

  • Ccformat: This is a mandatory parameter and is used as part of the command line parameter when upload_cc_feed.bat is run. This can be in any format accepted by the Expense Management system.
  • Feedfile: This is a mandatory parameter and is used as part of the command line parameter when the upload_cc_feed.bat is run. This is the location of the cc file that must be uploaded.
  • cc.uploadGetLogFileOnly: Set this parameter to true to retrieve just the log file associated with the specified feed file. The feed file is not imported or uploaded. The default is false.
  • cc.uploadOverwrite: Set this parameter to true if you want to overwrite a feed file on the server of the same name. The default is false.
  • cc.uploadCurrencyCode: This parameter specifies the currency used by the importer for card limits. Default is USD.
  • cc.archiveLogInOneFile: This parameter is used to get individual cc log file. Setting cc.archiveLogInOneFile=true in the bkg parameter creates a new log file for every XMDBToolBKG.CC run.
  • cc.filepat: This is a new parameter that is given as part of the XMDBToolBkg.CC background parameters. This specifies the file pattern. If the customers have multiple files (for example; KR1205 and KR1025), it helps to have the ability to only process one type of file based on the file names. For example, if the cc.filepat = KR1205, the bkg will only select the cc files names with KR1205. Rest all files are NOT picked. Multiple file patterns are specified with an underscore. For example cc.filepat=KR1205_KR205. This picks the files with KR1205 and KR205 in the filenames. Rest all files are picked.
  • cc.blockrun:The XMDBTool ensures that files are picked up in blocks before they are processed, if the value of this parameter is set to true. If a value is not specified, the XMDBTool loads all the files to the memory before processing the files.
  • xmdbtool.ccblockrunsize: This parameter is used to specify the size of the block, in MB, where each block consists of one or more number of cc files. The number of files in each block will not exceed the size specified. The default value of this parameter is 1000 MB.

Running CC Process in a new Thread

You must enable the new cc.threadEnabled flag in the xmdbtool.properties file and set the value to true, to run a new CC upload process. By default, the value is set to false.

When the value of the cc.threadEnabled flag is set to true, the XMDBTool client initiates a call to the server and transfers the CC file to the server. The server starts a new thread for the CC file upload process and returns to the client. The new thread enters the alex_xmdbtool_etl table with the start_date set to the current date and script_type set to CCDONE. The value of the is_active_script is updated to 1, after the thread is complete and the cc upload process ends.

The XMDBTool client pings the server periodically and monitors the db table to check the status of the upload process.

If the upload process is complete, the flag generates the log, renders the flag in the client machine, and exits. Before exiting, as part of the clean-up, the server sets the value of the is_active_script to 0 and sets the end_date.

If the upload process is not complete, the XMDBTool client constantly calls the server (currently set to 1-minute interval) until the process is complete. Therefore, avoiding the time-out issue, as the XMDBTool is not ideally waiting on the server.

Note: If the cc.threadEnabled value is not set to true, the cc upload process runs without creating the process as a separate thread.