This chapter describes how to administer the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer.
This chapter includes the following sections:
Increasing Memory to Improve Performance of Large File Transfers
Transferring Files Through Firewalls Using the MFT FTP Proxy Server
Configuring Oracle Managed File Transfer Error Processor Queues
For information about keystores, see Managing Keystores.
For information about domains, see Managing Domains.
For information about administering Oracle Managed File Transfer embedded FTP and sFTP servers, see Administering Oracle Managed File Transfer Embedded Servers.
The Server Properties tab on the Administration page is arranged in the following sections:
To save changes to these properties, click Save. To cancel all changes since you last saved, click Revert.
The Server Properties tab displays the following configurable fields:
The default Payload Storage Directory is WLS_Home/user_projects/domains/base_domain/mft/storage. You must set it to a shared location if multiple Oracle WebLogic Server instances run in a cluster.
WLS_Home/user_projects/domains/base_domain/mft/callouts.Store Inline Payload: The Store Inline Payload setting determines whether inline payloads are stored in the File System or a Database after transfer. You must select one of the options.
Store Reference Payload: The Store Reference Payload checkbox determines whether referenced payloads are stored in the payload storage directory. If you check this box, the Payload Storage Directory specifies the file system location, if you do not select the checkbox, then no reference payload will be persisted.
To change the Payload Storage Directory:
Stop the Oracle WebLogic Server managed server(s) dedicated to Oracle Managed File Transfer.
Change the Payload Storage Directory setting.
Move the directories and files under the Payload Storage Directory.
Restart the managed server(s).
See Re-configuring the Port for how to stop and start the managed server(s).
Generate Checksum: The Generate Checksum setting helps you verify that all the bits in a file were successfully transferred. If this box is checked, Oracle Managed File Transfer generates a checksum for every payload before delivering it to target and stores it in the database. This checksum can then be compared to verify that the file was not corrupted during transfer.
Note:
Checksum is necessary to validate the payload in the later stage. This is an optional field, if you do not need MFT to generate checksum, then do not select this field. This will avoid additional checksum computation thus increasing the performance.The Processors settings determine the number of processing threads dedicated to each stage of file delivery. The default for all three settings is 2.
Source Processors: determines the number of message processors required at the source level. This handles transfer identification and source-level processing function execution.
Instance Processors: determines the number of message processors required at the transfer level. This handles target-level preprocessing function execution.
Target Processors: determines the number of message processors required at the target level. This handles delivery and target-level postprocessing function execution.
In most cases, this number has to be more because much of load like target message processing or delivery happens in this layer. So usually this can be higher than other two types processors.
Based on the transfer configuration, processing functions defined, and expected payload pattern, you might want to increase of decrease the number of threads assigned to each Processors setting. For example, if the time taken for target preprocessing is short compared to delivery, you might want to reduce the number of Instance Processors and increase the number of Target Processors for optimal performance.
Oracle Managed File Transfer uses the collision detection feature of the internal JCA adapter to prevent thread concurrency issues.
These settings are JCA adapter properties for high availability:
Control Directory is the directory path which MFT File/FTP adapters require to handle HA use cases. This field is required if the MFT is running in HA environment. You must set it to a shared location if multiple Oracle WebLogic Server instances run in a cluster, for example $DOMAIN_HOME/mft/control_di.
Inbound Datasource is the inbound data source of MFT where the schemas corresponding to high availability are precreated. This field is required if the Control Directory is not provided. The default, established outside of Oracle Managed File Transfer, is jdbc/MFTDataSource.
Outbound Datasource is the outbound data source of MFT where the schemas corresponding to high availability are precreated. This field is required if the Control Directory is not provided. The default, established outside of Oracle Managed File Transfer, is jdbc/MFTDataSource.
For more information, see Configuring Oracle File and FTP Adapters for High Availability in Understanding Technology Adapters.
The Advanced Delivery settings are required when Oracle WebLogic Server instances are run with a load balancer. These settings capture the Internal Address and External Address (IP addresses) and the FTP, FTPS, and sFTP ports that the load balancer uses. Use this setting when Oracle Managed File Transfer sends a payload as an FTP or sFTP reference. If the values are set, they are used to construct the FTP reference (FTP/sFTP host address and ports).
Internal Address: Internal proxy address and ports needed for reference delivery cases.
External Address: External proxy address and ports needed for reference delivery cases.
If Oracle MFT is running behind internal and external proxies, then the Internal and External IP addresses are required.
For more information, see Load Balancing in a Cluster in Administering Clusters for Oracle WebLogic Server.
A backup of the Oracle Managed File Transfer configuration (or repository) includes all Administration page settings and all Designer artifacts, excluding password settings. The configuration is saved to a ZIP file, which you can restore later.
The steps for this process are:
Open the Import/Export tab on the Administration page.
Click Export.
An operating system dialog box opens asking what action to take with the file export.zip.
Select Save File and click OK.
An operating system file saving dialog box opens.
Select the directory to which to save the file.
Edit the file name. This is optional.
Click Save.
You can restore a backup of the Oracle Managed File Transfer configuration. This overwrites the existing configuration except for password settings.
To import or export a single transfer artifact, see Importing and Exporting Transfers.
You can use the exportMftMetadata and importMFTMetadata WLST commands to back up and restore the Oracle Managed File Transfer configuration. For more information, see MFT Metadata Commands in WLST Command Reference for SOA Suite.
Keystores are not part of the Oracle Managed File Transfer configuration. For more information, see Managing Keystores.
If transfers of large files are running slowly or out-of-memory exceptions occur, increase the memory (-Xms) or heap size (-Xmx) to 1 or 2 GB. For example, the following command increases the memory to 1 GB and the heap size to 2 GB:
setenv USER_MEM_ARGS "-Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=768m"
You can start, restart, or stop the Oracle WebLogic Server managed server(s) dedicated to Oracle Managed File Transfer from the Oracle Managed File Transfer console.
Embedded servers are not the same thing as Oracle WebLogic Server managed servers. The MFT embedded FTP and sFTP servers are services that run on the Oracle WebLogic Server managed server(s) dedicated to Oracle Managed File Transfer. The MFT console page for embedded server ports management lists these managed servers and allows you to stop and start them.
The steps for this process are:
On the left pane of the Administration page, click the arrow to the left of Embedded Servers.
The Ports and User Access items appear.
Click Ports.
The Embedded Server Ports tab opens.
Select the Server Instance that you want to start, restart, or stop by checking its box in the table. To perform an operation on all servers, check the Select All box.
Look at the Server Status. You can stop or restart the server if it is RUNNING. You can start the server if it is STOPPED.
Click Start, Stop, or Restart.
Click the Refresh icon to update the table and verify the new Server Status.
The primary purpose of the Ports tab is updating embedded server ports. For details, see Re-configuring the Port.
To start and stop only the embedded FTP and sFTP servers, see Starting and Stopping Embedded Servers.
For more information about how to manage Oracle WebLogic Server startup, shutdown, and failure recovery, see Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.
Oracle Managed File Transfer includes the MFT FTP Proxy Server, which has the following characteristics:
Supports the FTP, sFTP, and FTPS protocols.
Resides separately outside a firewall, eliminating the need to deploy MFT outside the firewall.
Accepts external FTP requests and forwards them to MFT servers inside the firewall.
Typically connects to a single hardware load balancer.
Supports standard gateway and reverse proxy use cases.
Allows for configuration of ports and inbound server IP addresses.
Supports the use of any standard FTP client.
The following is a simple topology:
FTP Client > MFT FTP Proxy Server > Hardware Load Balancer > MFT Server Cluster
The files that comprise the MFT FTP Proxy Server are located in WLS_HOME/mft/applications/proxy/config. The Readme.txt file describes how to configure and deploy the MFT FTP Proxy Server.
For more information about setting up firewalls, see Security Options for Cluster Architectures in Administering Clusters for Oracle WebLogic Server.
Remote SFTP with Proxy Server
When Transport Provider is set as Socket, connection to remote server is direct, it does not use the proxy definition. When Transport Provider is set as HTTP, the connection to remote SFTP server is through a proxy server. If the proxy details are not entered or is invalid, then delivery will fail. When Transport Provider is set as HTTP and proxy settings are defined and are valid, MFT will deliver the file to target via proxy server.
Oracle Managed File Transfer runs on Oracle WebLogic Server. Therefore, setting up high availability for Oracle Managed File Transfer depends on setting up high availability for Oracle WebLogic Server.
This section includes the following topics:
The high-level steps for this process are:
Set up the JCA adapter properties for high availability during Oracle WebLogic Server configuration. You need these for setting High Availability Properties. For more information, see Configuring Oracle File and FTP Adapters for High Availability in Understanding Technology Adapters.
Create a cluster of managed servers during the domain configuration step of Oracle Managed File Transfer installation. For more information, see Configuring a Cluster for Oracle Managed File Transfer in Installing and Configuring Managed File Transfer.
Install a software or hardware load balancer. Note the Internal Address and External Address (IP addresses) and the FTP, FTPS, and sFTP ports that the load balancer uses. You need these for setting Advanced Delivery Properties. For more information, see the load balancer documentation.
Configure High Availability Properties and Advanced Delivery Properties in Oracle Managed File Transfer and Save them.
Restart each managed server. See Oracle WebLogic Server Startup and Shutdown.
For more information about topics such as cluster topologies, virtual IP addresses, load balancing options, failover, and so on, see Understanding WebLogic Server Clustering, Virtual Server IPs and Pool, and Load Balancing in a Cluster in Administering Clusters for Oracle WebLogic Server.
If the Oracle WebLogic Server cluster uses unicast messaging, and the servers in the cluster don't synchronize right away, you might see a message such as the following when the cluster restarts:
<Error> <oracle.soa.adapter.jms.inbound> <BEA-000000> <JMSMessageConsumer_init:[destination = MFTJMSServer_auto_2@jms/mft/MFTSourceQueue (payload = 1)]:ERRJMS_ERR_CR_QUEUE_CONS. Unable to create Queue receiver due to JMSException.
You might see messages such as the following in a stack trace:
weblogic.jms.common.JMSException: could not find Server mft_server1 javax.naming.NameNotFoundException: Unable to resolve 'weblogic.messaging.dispatcher.S:mft_server1'. Resolved 'weblogic.messaging.dispatcher'; remaining name 'S:mft_server1'
You can usually ignore these messages, because server synchronization is retried and usually succeeds. If you prefer not to see this message, do one of the following:
Set the Member Warmup Timeout Seconds MBean attribute to 30. This delays synchronization, giving the servers in the cluster time to start up first.
Use multicast messaging, which sets the default of Member Warmup Timeout Seconds to 30.
For more information, see "Communications In a Cluster" in Administering Clusters for Oracle WebLogic Server.
Oracle Managed File Transfer has mechanisms to ensure that in a cluster, only one Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer executes a particular file transfer instance. Load balancing of transfers is sticky.
If a managed server fails while a transfer is in progress, the transfer is automatically resubmitted when that managed server restarts.
You can notify specific users about Oracle Managed File Transfer events such as errors or new artifact deployments. Oracle MFT uses UMS for notification.
To notify specific users about events, you configure notifications using WLST commands for Oracle Managed File Transfer, then you configure the email or SMS driver. Notifications event types are as follows:
RUNTIME_ERROR_EVENT — Errors during events such as message processing, server start-up, source error, or system event failure error.
DELETE_ARTIFACT_EVENT — Deletion of a transfer, source, or target.
DEPLOY_ARTIFACT_EVENT — Deployment of a transfer, source, or target.
EXPORT_IMPORT_EVENT — Import or export of the MFT configuration.
PURGE_EVENT — Purging of runtime transfer instances or transfer payloads.
ARCHIVE_RESTORE_EVENT — Archiving or restoring of runtime transfer instances or transfer payloads.
All notification messages are sent to JMS MFTExceptionQueue, whether or not they are enabled or there are contacts to be notified.. For more information about MFT Exception Queue, see MFTExceptionQueue.
The steps for enabling event notifications are:
By default all the event notifications are disabled. Use the following WLST commands to enable the MFT Notifications. For information on WLST commands, see Running WLST Commands.
Use following WLST commands to start:
Start WLST console using command: $MW_HOME/mft/common/bin/wlst.sh
Connect to MBean server: connect("adminusername","adminpassword","t3://localhost:mft–port"). Port is the configured port of mft server.
Once connected, run following commands.
Create users, or contacts, to notify. For example: createContact('Email', 'jane.doe@example.com')
Associate contacts with the notification events. For example: addContactToNotification('DEPLOY_ARTIFACT_EVENT', 'Email', 'jane.doe@example.com')
Enable the notification event. For example: updateEvent('RUNTIME_ERROR_EVENT', true)
The notification is enabled for the run-time message processing errors. Any runtime message error will be notified via email to specified email address.
For notifications of type EMAIL or SMS to work, you must configure an email or SMS driver. See Configuring an Email Driver for Notifications or Configuring an SMS Driver for Notifications for more information.
For more information about WLST notification commands for Oracle Managed File Transfer, see MFT Event Notification Commands in WLST Command Reference for SOA Suite.
Note:
By default all User Messaging Service (UMS) channels are enabled with the Oracle specific-settings (mail server). External customer need to change these settings in the Enterprise Manager for notification to work.The steps for this process are:
The current defaultFromEmailAddressForNotification Mbean property to change the default sender address used for notifications is no.reply@oracle.com.
For more information about configuring the email driver in Fusion Middleware Control, see Configuring the E-Mail Driver in Administering Oracle User Messaging Service.
Use Oracle Enterprise Manager Fusion Middleware Control to configure the SMS (or SMPP) driver for event notifications.
Note:
By default all User Messaging Service (UMS) channels are enabled with the Oracle specific-settings (mail server). External customer need to change these settings in the Enterprise Manager for notification to work.The steps for this process are:
For more information about configuring the SMS driver in Fusion Middleware Control, see Configuring the SMPP Driver in Administering Oracle User Messaging Service.
When you install MFT, the MFT installer creates a JMS queue called MFTExceptionQueue. This queue is used to trace events for notifications that are not configured. To trace events, the server checks if any notification is enabled for a event. If the notification is not enabled, then the same message is published in the MFTExceptionQueue.
By using JMS MFTExceptionQueue, you can track the following events:
Table 6-1 Events
| Events | Description |
|---|---|
|
RUNTIME_ERROR_EVENT |
This event tracks the errors occurred at runtime. For example:
|
|
EXPORT_IMPORT_EVENT |
This event tracks both export and import events. If notification is not configured, MFT submits a message in exception queue. For example, a sample message has a whole repository export. This message is submitted only when an event is successful. |
|
DEPLOY_ARTIFACT_EVENT |
This event tracks the artifact deployment events. If a notification is not configured, MFT submits a message in exception queue. For example, a sample message indicates a deployment event for a source, for example,“osbsrc1". This message is submitted only if the deployment is successful. |
|
DELETE_ARTIFACT_EVENT |
This event tracks tip metadata deletion. For example, source, transfer and target deletion. |
|
PURGE_EVENT |
This event tracks the runtime/payload purge. MFT submits a message in exception queue when runtime/payload purge is executed. This message is submitted on successful completion of purge only if notifications are not configured. For example, a sample message shows a runtime purge. |
|
ARCHIVE_RESTORE_EVENT |
This event tracks the runtime / payload archive and restore. MFT submits a message in exception queue when archive / restore is executed for runtime/payload data. This message is submitted on successful completion of event only if notifications are not configured. For example, a sample message shows a runtime archive event. |
You can configure JMS queues to receive MFT runtime error events using the Oracle WebLogic Server Administration Console.
The preexisting MFT runtime processor queues are:
MFTSourceQueue
MFTInstanceQueue
MFTTargetQueue
This section describes how to create corresponding error queues for each of these runtime processor queues.
In MFT, messages are processed asynchronously. A single MFT message is processed by three different processors and for each of these processors, there is a corresponding queue as listed below:
Table 6-2 Processors and Queues
| Processors | Queues |
|---|---|
|
Source Processors |
MFTSourceQueue |
|
Instance Processors |
MFTInstanceQueue |
|
Target Processors |
MFTTargetQueue |
Also, every MFT message corresponds to a JMS message for each of these processors. There can be exceptions to any of the error processor queues.
The expected and unexpected system-level errors are handled in the following way:
Expected system-level errors: For every expected system-level error such as file not found there is a corresponding MFT message which is marked as “Error".
For delivery related expected errors such as remote server down, the corresponding message is retried based on the retry settings in the target. For other expected errors, there are no retries.
Unexpected system-level errors: If there are unexpected system-level errors such as rac failures or JMS failures, MFT retries the JMS message three times. If all retries are exhausted, then the MFT messages are stuck in active status. The corresponding JMS message is purged or not depends on whether the JMS processor error queues are associated with MFT processing queues.
By default, the error processing queues are not configured. If this is the case, the JMS messages are purged otherwise the JMS messages are redirected to configured error queue.
If transfer instances are stuck in active status for a long time, you can check these error queues. The JMS messages in the error queues have the complete details of the transfer instances. You can search for the message ID in the MFT log files to find the root cause (error stack). Once the issue is resolved, you can re-send the JMS message to corresponding runtime queue for reprocessing.
The steps for creating error queues are:
MFT component log messages are written to the log file at this location:
WLS_HOME/user_projects/domains/base_domain/servers/mft_server1/mft_server1-mft-diagnostic.log
MFT embedded server log messages are written to the log file at this location:
WLS_HOME/user_projects/domains/base_domain/servers/mft_server1/mft-es/mft_server1-mft-es-diagnostic.log
You can use Oracle Enterprise Manager Fusion Middleware Control to change the sizes of these log files and to set the log level for the various loggers that write messages to these log files.
The steps for this process are:
Log in to the Fusion Middleware Control console.
In the Target Navigation pane, expand the Weblogic Domain node.
Expand the node for the domain on which the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer is installed.
For example, the domain might be soainfra or base_domain.
Right-click on the MFT server.
For example, the MFT server might be mft_server1.
Select Logs > Log Configuration.
Select the Log Files tab.
Select odl-handler and click Edit Configuration.
Edit the Maximum Log File Size (MB) and Maximum Size of All Log Files (MB) values and click OK.
Select the Log Levels tab.
Expand the Root Logger node and any other nodes necessary to display the loggers for which to set log levels.
Table 6-3 lists the loggers relevant to MFT components. Table 6-4 lists the loggers relevant to MFT embedded servers.
For each logger, select the desired Oracle Diagnostic Logging Level (Java Level): SEVERE+100, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, or FINEST. The default is INFO.
Check Persist log level state across component restarts if necessary.
Click Apply.
Table 6-3 MFT Component Loggers
| Logger Name | Logged Events | Default Level | Production Level |
|---|---|---|---|
|
|
Message processing, processing functions and callouts, deployment operations |
INFO |
SEVERE |
|
|
Transport layer interaction operations, system events |
INFO |
SEVERE |
|
|
Audit, notification, purge, archive, restore, server startup, common utility APIs |
INFO |
SEVERE |
|
|
Java persistence operations |
INFO |
SEVERE |
|
|
WLST and EJB invoked API handling |
INFO |
SEVERE |
|
|
Schedule operations |
INFO |
SEVERE |
|
|
Embedded server communication with the MFT server |
INFO |
SEVERE |
|
|
Security operations, OWSM local policy |
INFO |
SEVERE |
|
|
Console operations |
INFO |
SEVERE |
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
|
|
|
INFO |
SEVERE |
Table 6-4 MFT Embedded Server Loggers
| Logger Name | Logged Events | Default Level | Production Level |
|---|---|---|---|
|
|
FTP operations |
INFO |
SEVERE |
|
|
sFTP operations |
INFO |
SEVERE |
You can use Oracle Enterprise Manager Fusion Middleware Control to view messages in the Oracle Managed File Transfer log files.
The steps for this process are:
You can move Oracle Managed File Transfer from a source environment, such as a test environment, to a target environment, such as a production environment. Oracle Fusion Middleware provides scripts to copy an Oracle home and domains, as well as the configuration of Oracle Managed File Transfer, from one environment to another. As part of the procedure, you extract a move plan from the source environment, which contains properties that you can then edit to provide the values for the target environment.
For more information, see Moving from a Test to a Production Environment in Administering Oracle Fusion Middleware.