Basic function of FNDFS
======================
1) The user selects ‘Request Output’, ‘Request Log’, or ‘Manager Log’
2) The file name and nodename are selected from the database Reports:
Outfile:
SELECT outfile_name, outfile_node_name FROM fnd_concurrent_requests WHERE request_id = :id;
Logfiles:
SELECT logfile_name, logfile_node_name FROM fnd_concurrent_requests WHERE request_id = :id;
Manager logs:
SELECT logfile_name, node_name FROM fnd_concurrent_processes WHERE concurrent_process_id = :process_id;
3) The client takes the nodename that was returned and adds FNDFS_ to the beginning of it. For example, if xprod_ser1 was returned as the node name, the client would construct the string: FNDFS_xprod_ser1
4) The client takes this string and attempts to use it as a SQL*Net connect descriptor. SQL*Net will attempt to resolve this descriptor into a host and SID using a local tnsnames.ora file or Oracle Names.
5) If successfully resolved, a connection is made to the given host. The listener on this host receives the connection request, and resolves the SID using its listener.ora file. If it finds a PROGRAM parameter listed for this SID, it will launch this program. (which should be $FND_TOP/bin/FNDFS)
6) The FNDFS executable runs. The client sends RPC commands to it to return the requested file.
Common error :
An error occurred while attempting to establish an application file server connection with the node There may be a network connection
problem or the listener on node may not be running.
-This can indicate a multitude of problems, and unfortunately, it does not display anymore helpful messages.
-This most commonly indicates a problem with the local tnsnames.ora file or the listener.ora file on the server. Check that the customer added an FNDFS entry to the tnsnames.ora file.
-Check that the hostname and port are correct. Make sure that the entry is named FNDFS_hostname. Also, if the customer has edited the file himself, he may have inadvertently corrupted the file. SQL*Net is very picky about the syntax of this file.
-An extra space or carriage return could cause RRA to fail. The only supported method of editing this file is to use Network Manager. Have the customer backup the old file, then create a new one with Network Manager if you suspect that this file may be bad.
-Once you are sure the tnsnames.ora file is correct, you should be able to use TNSPing to ping the listener. (Be sure to ping the FNDFS alias) It should return an OK result.
-Errors here may indicate that the listener is not properly set up.
-Make sure that you are using the exact name of the server (check this with: uname -n) If you have the wrong name in the tnsnames file entry, the tnsping will work, but RRA will not. For example, suppose the server’s real name is XPROD_SER1, and you
create a tnsnames entry called: FNDFS_DBSERV because you have a DNS alias for this server. You can ping the server normally, because DNS will resolve this name for you. You can run TNSPing with FNDFS_DBSERV and it will resolve this connect string and it will ping the server and return an OK result. This would lead you to believe that everything is OK on the client side. However, RRA still does not work. This is because RRA is using the real server name, and it is trying to resolve the connect string NDFS_XPROD_SER1, and this entry does not exist. A client-side trace would discover this error.