In this pattern, a directory is nominated to hold data files to be used for interface processing, possibly generated by a source system that cannot be accessed by other means, such as a web service call or a query. In Jitterbit a file source is created that may contain the file name or a wildcard, and after processing the file, is either deleted or changed in such a way that it will not be picked up on the next run. The file source can be a local file (local to the Jitterbit Agent, that is) or it can be the temp directory, which has the advantage of being cleared out periodically by Jitterbit and can be accessed easily without changing configuration files.
NOTE: This design pattern uses Design Studio as an example; you may apply the same concepts in Cloud Studio using similar steps.
In this example, SAP is sending price files that cannot be accessed via an IDoc or BAPI. The entire operation is too complicated to review in depth, but we can look at the file handling aspects.
The first operation checks if any files exist to be processed, the second operation launches another operation that is not germane to this discussion, and the third performs an upsert to SFDC.
This script checks if a file exists in the source and if so, launches the next operation:
If(Length(FileList("<TAG>Sources/ORPG Local Host</TAG>"))>0,RunOperation("<TAG>Operations/Discount - ORPG/DI1.1 Get ORPG Sec 1</TAG>"))
Skipping the second operation, the third operation reads the source file and deletes it after processing by simply checking the Delete File option.