cancel
Showing results for 
Search instead for 
Did you mean: 

Processing the data-control pairs of files

Former Member
0 Kudos

Hi All,

The scenario should always check on FTP server for control files (like *.ctrl), and if, for example, AFILE.ctrl file is fetched, then AFILE.dat file should also be fetched somehow from the server and both files have to be processed to another server.

What is the best solution for this kind of task?

I am thinking about some kind on synchronous call to FTP server after recieving control file, to get the data file, but I guess this is impossible with File adapter.

So any ideas?

Best Regards,

Artsiom Anichneka

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

I would suggest you go for a BPM here.

Use 2 receive steps. One for receiveing control file and the other one for receiveing data file.

Make the correlation based on FileName (context objects)

Ensure you enavle the File Name option under Adapter Specific Message Attributes for both the sender file communication channels.

Regards,

Jai Shankar

Former Member
0 Kudos

Jai, thanks for your answer.

But in the solution you have provided the data file in some cases will be picked up even if there is no trigger file, which is not OK.

And another problem is that we can't correlate on filenames, as they have different extensions (.dat and .ctrl). Or maybe it is possible to use functions (like substring), when correlating on context object? If yes than please tell me how.

Best Regards,

Artsiom Anichenka

Former Member
0 Kudos

Hi Artsiom,

Forgot about thedifferent file extensions. You are correct, we can not use FileName for correlation.

The work around for this is to develop an adapter module that inserts a keyfield in the payload, the value of this field will be the file name with out extension.

Make a correlation based on this field and ignore this field in mapping.

Regarding your other problem, try to do this from your sender application.

Keep us posted on how you procced with this interface.

Regards,

Jai Shankar