Total of 5 videos on this page.
Back to XT Server page
#1. Setup basic XTranslator 1.x translation
We create new job and add File Polling task to it
File Polling checks input folder for specific files using wildcard and runs translator if files exist
Then job runs translation using 837 to CSV map
Since it is testing mode we also add Exit task. Without Exit task job would restart from first task
XT Server is designed to run automated processing. Jobs run in the loop until encounter Exit task or error
When all the tasks are added and tested remove Exit task so job could run continues translations everytime new input files come in
#2. Setup delete task to clean up input files
Once translation is done we want to clean up input files
This is done using File Delete task
We also add Log task to print DONE message in the log
#3. Setup EDI validation for incoming files
We setup EDI X12 validation. There are four main directories.
Input directory where validation will pick up files
Fail directory for files that fail validation
Success directory for files that pass validation and might be processed with other tasks
Output directory is for output reports with validation results. Such as 997, 999 acknowledgements or CSV, text files with list of errors
We setup directories and then run tests to make sure validations run
Recap: after validation runs input files end up in fail or success directory. Output directory is for validation reports: 997, 999, HTML, CSV, etc
#4. Add XTranslator 1.x task after EDI validation
Once EDI validation runs we want to process valid files using translator
We add XTranslator task and set input directory to read files from EDI validation success directory
There is also task called 'XTranslator 2'. This task is reserved for future use when XTranslator version 2.0 will be released.
#5. Run server via command line
There are no parameters for basic execution
Press Ctrl-C keyboard shortcut to stop processing
Bonus. Pro tips
Plan your directory structure. This can not be stressed enough
Most work is done on files. So having specific directories for specific actions makes sense
Example: let say we want to do EDI X12 837 and 835 translations. We setup root directory under 'C:\prod\'
Then we add subdirectories 'C:\prod\837\' and 'C:\prod\835\' .
Then we create all specific processing steps in each: like 'C:\prod\837\validate\' then 'C:\prod\837\translate\' and so on
If we will have to add message type in the future (eg. EDI X12 270) it will be obvious how to set it up
This also helps to solve issues if something fails: if 837 processing failed you will know what directories to check