File Channel Issues with Landmank/IPA on Seperate Server than LSF

We encounter some issues with the "File Channel" service (ScanFile Client) when the Landmark server is on a separate server from LSF. We went with separate server due to implementing APIA (Invoice Automation) due to Infor's recommendations.
The main issue is that the File Channel Service can only detect from drives on the landmark server, so in order to detect a file on the LSF server, we have to create a File Share on the Landmark server that points to the LSF server location. While this works, it's not supported per Infor.
Additionally, if we need to pick up a file from LSF and edit/process and put it back, this in effect takes 2 processes, 1 to pick it up, 1 to put it back, all through the "file share" created on Landmark. This means we may also need to move the file within LSF, before and after, to get it in the right place.

Quite a bother and cumbersome, so looking to see if anyone else has overcome these challenges.

Find more posts tagged with

Comments

jreese

We have our File Channel detecting files on the LSF server without any problems. The only files that we saw that appear to be on the Landmark server are the Error File Directory and the In-Progress File Directory.

Legacy Contributor

IPA File Channels have a setting called "File Channel Type". If you choose "Remote" as the type then IPA will access the remote server via FTP to get the files. Have you tried this? Does this work to retrieve your files from the Lawson server?

Legacy Contributor

We were using the Remote option. The issue is that once the scan takes place the file is automatically moved to either the error or processed directories which reside on the Landmark server. There is no option that I'm aware of (or Infor for that matter) for either of those directories to point to the origin LSF environment without creating a shared drive on the Landmark server that points to LSF (which is not supported by Infor). When LSF and Landmark both reside on the same server that is no longer an issue because files that are scanned/archived/error can all point to local directories.

We are scanning a directory in LSF, when a file is present a job is then kicked off that uses that file. Some programs do not have the ability to identify where it looks for the input file. If File Channel moves the file to landmark, we then have to FTP it back to the original folder, run the job, then move the file again to an archive directory. Just seems overly complicated for a simple flow to monitor for existence of a file, run a job, archive the file in PFI.
This is just one scenario where we are left scratching our heads.

jreese

What do you mean by "Some programs do not have the ability to identify where it looks for the input file"? We have a process that scans for a file on the LSF server and once found, it reads through the file and processes the records into Lawson.

Legacy Contributor

Sorry, that statement is really unnecessary on my part in explaining the issue.
When the file is detected, File Channel automatically moves it to the Landmark server. LSF programs such as AP520, IC527, CB554 etc can't then pick up the file from Landmark unless we FTP it back over to the LSF server.

bhillz

What other options are there for transferring the file? SCP, SFTP or secure??? FTP is an insecure protocol.

Legacy Contributor

it's all within our network so not really a security issue. That being said most of our FTP's are actually SFTP's I always just neglect to put the 'S' since I take it for granted. At any rate, that has no bearing on our issue.

Legacy Contributor

I am not sure I understand you. We use File Channel to detect files on our LSF server and it doesn't move them to our Landmark server. It just detects the file is there and then kicks off the flow. We do use File Sharing, but I have never been told that Infor doesn't support it and even if they don't it works. We run our flow under the product line that is tied to our LSF product line and it is the flow that determines where the file read from and placed. In the "main" (default) configuration in the Lawson tab we point it to our LSF server. What do you have for your server in the Lawson tab for your "main" configuration?

jreese

I believe the difference at least between how we are using the File Channel and how darringt is using it, is that we process the contents of the file through a data iterator node and the flow and darringt is using it to trigger a flow that has webruns in place to run standard Lawson jobs, like AP520, that requires the file for processing.
I looked at the File Channel documentation and it says that entering a Processed File Directory is Optional. Have you attempted to remove that entry to see if the File Channel then leaves the file in the original directory?

Legacy Contributor

JamesY, After File Channel detects a file, it has to move it or else it would keep detecting the same file over and over.
We have tried many options, worked with Infor Prof Services/Implementation, Support etc and the only way we can get it to work support says is not supported, the file share created on the Landmark that points back to the LSF server.

Just looking to see what the creative minds of the user community may have done differently or if you just went with what works and is not supported.

Robert Canham

I haven't done this, but what if the first step of your triggered flow is to ftp the file from the processed directory on Landmark to the location on the LSF server that the program is going to pull it from?

jreese

I have never used this approach, but I know with the old ScanFile Client, you could drop a dummy file in a directory, just to use as a way to notify the ScanFile Client that there was a file ready to process. So you could create a Cron job that looked for the file needed by AP520, etc. and once found create an empty file for the File Client to find and trigger the flow. Once the Lawson job has completed and no longer needs the file you could then delete or move the file to another location.

Legacy Contributor

Ah! When I responded previously I did not get that you did NOT want to touch the file on the LSF server. If that is the case, then you should NOT use the File Channel. Instead, use the Process Scheduler to run your Process every so often. Then, add a File Access node to the beginning of your Process model. Set the action of the File Access node to "Check File Exists". If the file exists, proceed with running your System Command to fire off the Lawson job. If the file doesn't exist Branch and go to the End node.
Hopefully I understood your request correctly.

Legacy Contributor

jreese, in response to your prior post, you are correct we use the WebRun node. I've asked and waiting to hear back to see if the data iterator node may provide some other options, but I think not from what I know if it (very little).
As far as that config option, if that value is blank it defaults to the Processed folder on Landmark. I think that option is to allow you to define a different place to put it, but it has to be a Landmark file path. We put the file share file path there and we can get it to work, but run into the "unsupported" issue.

I'll think about the cron job, but again seems like so many extra steps for such a simple process if we would just put landmark and LSF on the same server. We are not past the point of no return, so we may end up going that route and just tripling resources recommended to avoid any issues. Memory and space is cheap as they say!! Processors not so much but... lol

Legacy Contributor

Keith, thanks, I think that would work as well, much like jreese's option. Still adding what we feel is unneeded complexity to a relatively simple flow.
We just need to evaluate things and see what effort brings the best return I guess.
This simple concept of detecting a file to be used for processing, is often just the beginning of much more complicated flows, detecting a file and then 30-40 nodes later sending reports, saving outputs etc and adding this complexity to just the simple flow is looking at exponentially increasing it on our more complex ones.

Good suggestions though. Any other thoughts appreciated. I don't mean to shoot down any right off the bat to dissuade further thoughts so forgive me if I seem to. Just need to find the best, or least worst, solution for us.

Legacy Contributor

"adding this complexity to just the simple flow is looking at exponentially increasing it on our more complex ones. "

Its just two nodes added to the beginning of your existing ones; File Access and Branch.

Legacy Contributor

We will also then need something to remove/move the file etc. This certainly is an option we are exploring though. As well as a couple others.
The new scheduler also is a bit more cumbersome, though it offers a lot more flexibility.
Thanks for the input and options. If we find an ideal solution I'll share as well. As I said, we may just go ahead and put it on the LSF server.

Important Links

Community Hubs
Discussion Forums
Groups
Community News

Copyright © 2025 Infor. All rights reserved.