6 Administering Oracle Managed File Transfer

Learn how to administer the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer.

This chapter includes the following sections:

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.

6.1 Changing Server Properties

You can change or update server properties using the Server Properties tab on the Administration page.

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.

6.1.1 General Server Configuration Properties

The Server Properties tab displays the following configurable fields:

  • Payload Storage Directory: The directory location where the MFT payloads are stored. This has to be a shared location.

    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.

  • Callout Directory: The shared directory location where custom callout JARs are stored. MFT loads the callout jars from this location. The callout processing will fail if no required jar is present in the given location. The default location is 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.

    • If you select File System, the Payload Storage Directory specifies the File System location. If the configured inline payload size is more, then File System is recommended.
    • If you select Database, the payload is stored in the database that stores the Oracle Managed File Transfer configuration.
  • 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:

    1. Stop the Oracle WebLogic Server managed server(s) dedicated to Oracle Managed File Transfer.

    2. Change the Payload Storage Directory setting.

    3. Move the directories and files under the Payload Storage Directory.

    4. 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.

6.1.2 Performance Properties

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.

6.1.3 High Availability Properties

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.

6.1.4 Advanced Delivery Properties

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.

6.2 Importing and Exporting the MFT Configuration

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:

  1. Open the Import/Export tab on the Administration page.

  2. Click Export.

    An operating system dialog box opens asking what action to take with the file export.zip.

  3. Select Save File and click OK.

    An operating system file saving dialog box opens.

  4. Select the directory to which to save the file.

  5. Edit the file name. This is optional.

  6. 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.

6.3 Increasing Memory to Improve Performance of Large File Transfers

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"

6.4 Oracle WebLogic Server Startup and Shutdown

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:

  1. On the left pane of the Administration page, click the arrow to the left of Embedded Servers.

    The Ports and User Access items appear.

  2. Click Ports.

    The Embedded Server Ports tab opens.

  3. 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.

  4. 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.

  5. Click Start, Stop, or Restart.

  6. 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.

6.5 Transferring Files Through Firewalls Using the MFT FTP Proxy Server

Oracle Managed File Transfer includes the MFT FTP Proxy Server that supports the FTP, sFTP and FTPS protocols.

Note:

MFT Proxy is a standalone Java application and it does not support HA or clusters. The MFT Proxy Server is typically used to connect to a single hardware load balancer, which in turn communicates with MFT Managed Servers in a cluster residing inside the firewall. It is used in a development environment or where HA is not required. Oracle recommends not using MFT Proxy in a production environment. It may be used for internal testing purposes.

The MFT FTP Proxy server 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.

6.6 Managing Multiple Weblogic Servers and High Availability

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:

6.6.1 Configuring High Availability

The high-level steps for this process are:

  1. 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.

  2. 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.

  3. 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.

  4. Configure High Availability Properties and Advanced Delivery Properties in Oracle Managed File Transfer and Save them.

  5. 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.

6.6.2 Preventing Cluster Startup Errors

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.

6.6.3 Load Balancing in Oracle Managed File Transfer

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.

6.7 Enabling Event Notifications

You can notify specific users about Oracle Managed File Transfer events such as errors or new artifact deployments. Oracle MFT uses UMS for notifications.

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.

  1. 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.

  2. Create users, or contacts, to notify. For example: createContact('Email', 'jane.doe@example.com')

  3. Associate contacts with the notification events. For example: addContactToNotification('DEPLOY_ARTIFACT_EVENT', 'Email', 'jane.doe@example.com')

  4. 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.

6.7.1 Configuring an Email Driver for Notifications

Use Oracle Enterprise Manager Fusion Middleware Control to configure the email 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:

  1. Log in to the Fusion Middleware Control console.
  2. In the Target Navigation pane, expand the User Messaging Service node.
  3. Expand the usermessagingdriver-email node.
  4. Select the node for the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer. For example, this node might be named usermessagingdriver-email (mft_server1).
  5. In the usermessagingdriver-email page, select User Messaging Email Driver > Email Driver Properties to open the Email Driver Properties page.
  6. On the Email Driver Properties page, enter values for your mail server for the following (mandatory) Outgoing and (optional) Incoming Mail Server properties:
    • Outgoing Mail Server

    • Outgoing Mail Server Port

    • Incoming Mail Server

    • Incoming Mail Server Port

    • Incoming Mail IDs

    • Incoming User IDs

    • Incoming Passwords

  7. Click Apply.
  8. Log out and log back in to the Fusion Middleware Control console and verify that these properties are saved correctly.
  9. Restart the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer if necessary. See Oracle WebLogic Server Startup and Shutdown.

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.

6.7.2 Configuring an SMS Driver for Notifications

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:

  1. Log in to the Fusion Middleware Control console.
  2. In the Target Navigation pane, expand the User Messaging Service node.
  3. Expand the usermessagingdriver-smpp node.
  4. Select the node for the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer. For example, this node might be named usermessagingdriver-smpp (mft_server1).
  5. In the usermessagingdriver-smpp page, select User Messaging SMPP Driver > SMPP Driver Properties to open the SMPP Driver Properties page.
  6. On the SMPP Driver Properties page, click Create.
  7. On the Create SMPP Driver Properties page, enter values for the following properties:
    • SmsAccountId

    • SmsServerHost

    • TransmitterSystemId

    • ReceiverSystemId

    • TransmitterSystemType

    • ReceiverSystemType

    • DefaultSenderAddress

    • ServerTransmitterPort

    • TransmitterSystemPassword

  8. Click OK.
  9. Log out and log back in to the Fusion Middleware Control console and verify that these properties are saved correctly.
  10. Restart the Oracle WebLogic Server managed server dedicated to Oracle Managed File Transfer if necessary. See Oracle WebLogic Server Startup and Shutdown.

For more information about configuring the SMS driver in Fusion Middleware Control, see Configuring the SMPP Driver in Administering Oracle User Messaging Service.

6.8 MFTExceptionQueue

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.

All notification messages are sent to JMS MFTExceptionQueue, whether or not they are enabled or there are contacts to be notified.

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:

  • Any errors that occur during the message processing

  • Server start errors

  • System event failure errors

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.

6.9 Configuring Oracle Managed File Transfer Error Processor Queues

You can configure JMS queues to receive Oracle 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:

  1. Access the Oracle WebLogic Server console using a URL that includes the Oracle WebLogic Server hostname and the console port:
    http://wls-hostname:console-port/console
    

    For example:

    http://localhost:7011/console
    
  2. Log in using the Oracle WebLogic Server admin username and password.
  3. In the left pane of the Oracle WebLogic Server Administration Console, expand the Services node and the Messaging node under it.
  4. Select JMS Modules.

    The Summary of JMS Modules page appears.

  5. Select MFTJMSModule from the list of JMS modules.

    The Settings for MFTJMSModule page appear.

    Note that MFTSourceQueue, MFTInstanceQueue, and MFTTargetQueue are in the Summary of Resources list.

  6. Click New.

    The Create a New JMS System Module Resource page appears.

  7. Select Queue and click Next.
  8. Type a Name and a JNDI Name for the new queue and click Next.

    For example, you could type MFTSourceErrorQueue for the Name and jms/mft/MFTSourceErrorQueue for the JNDI Name.

  9. Select MFTSubDeployment from the Subdeployments drop-down list.
  10. Select MFTJMSServer from the Targets list.
  11. Click Finish.

    The Settings for MFTJMSModule page reappear with the new queue added to the Summary of Resources list.

  12. Select MFTSourceQueue from the Summary of Resources list.

    The Settings for MFTSourceQueue page appear.

  13. Select the Delivery Failure tab.
  14. Select Redirect from the Expiration Policy drop-down list.
  15. Select the new queue from the Error Destination drop-down list.
  16. Click Save.
  17. Select MFTJMSModule from the breadcrumb list at the top of the page.

    The Settings for MFTJMSModule page reappear.

  18. Repeat steps 6 through 17 to configure error queues for the MFTInstanceQueue and MFTTargetQueue JMS queues.

6.10 Configuring Oracle Managed File Transfer Loggers

MFT component and embedded server log messages are written in the configured locations. You can use the Oracle Enterprise Manager Fusion Control console to change the sizes of these log files or to set the log level for the various loggers that write messages to log files.

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

Use Oracle Enterprise Manager Fusion Middleware Control to modify the sizes of the log files and to set the log level for the various loggers. The steps for this process are:

  1. Log in to the Fusion Middleware Control console.

  2. In the Target Navigation pane, expand the Weblogic Domain node.

  3. 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.

  4. Right-click on the MFT server.

    For example, the MFT server might be mft_server1.

  5. Select Logs > Log Configuration.

  6. Select the Log Files tab.

  7. Select odl-handler and click Edit Configuration.

  8. Edit the Maximum Log File Size (MB) and Maximum Size of All Log Files (MB) values and click OK.

  9. Select the Log Levels tab.

  10. 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.

  11. 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.

  12. Check Persist log level state across component restarts if necessary.

  13. Click Apply.

6.11 Oracle Managed File Transfer Loggers

Use the MFT loggers table to understand the logger names, logged events and their default levels for MFT component and embedded server loggers.

Table 6-3 MFT Component Loggers

Logger Name Logged Events Default Level Production Level

oracle.mft.ENGINE

Message processing, processing functions and callouts, deployment operations

INFO

SEVERE

oracle.mft.TRANSPORT

Transport layer interaction operations, system events

INFO

SEVERE

oracle.mft.COMMON

Audit, notification, purge, archive, restore, server startup, common utility APIs

INFO

SEVERE

oracle.mft.REPOSITORY

Java persistence operations

INFO

SEVERE

oracle.mft.METADATA

WLST and EJB invoked API handling

INFO

SEVERE

oracle.mft.SCHEDULER

Schedule operations

INFO

SEVERE

oracle.mft.EMBEDDED_SERVER

Embedded server communication with the MFT server

INFO

SEVERE

oracle.mft.SECURITY

Security operations, OWSM local policy

INFO

SEVERE

oracle.mft.CONSOLE_UI

Console operations

INFO

SEVERE

oracle.mft.adapter.file

Not Applicable

INFO

SEVERE

oracle.mft.adapter.file.inbound

Not Applicable

INFO

SEVERE

oracle.mft.adapter.file.outbound

Not Applicable

INFO

SEVERE

oracle.mft.adapter.file.connection

Not Applicable

INFO

SEVERE

oracle.mft.adapter.file.transaction

Not Applicable

INFO

SEVERE

oracle.mft.adapter.ftp

Not Applicable

INFO

SEVERE

oracle.mft.adapter.ftp.inbound

Not Applicable

INFO

SEVERE

oracle.mft.adapter.ftp.outbound

Not Applicable

INFO

SEVERE

oracle.mft.adapter.ftp.connection

Not Applicable

INFO

SEVERE

oracle.mft.adapter.jms

Not Applicable

INFO

SEVERE

oracle.mft.adapter.jms.inbound

Not Applicable

INFO

SEVERE

oracle.mft.adapter.jms.outbound

Not Applicable

INFO

SEVERE

oracle.mft.adapter.jms.connection

Not Applicable

INFO

SEVERE

oracle.mft.adapter.jms.transaction

Not Applicable

INFO

SEVERE

Table 6-4 MFT Embedded Server Loggers

Logger Name Logged Events Default Level Production Level

org.apache.ftpserver

FTP operations

INFO

SEVERE

org.apache.sshd

sFTP operations

INFO

SEVERE

6.12 Viewing Oracle Managed File Transfer Log Messages

Use the Oracle Enterprise Manager Fusion Middleware Control console to view messages in the Oracle Managed File Transfer log files.

The steps for this process are:

  1. Log in to the Fusion Middleware Control console.
  2. In the Target Navigation pane, expand the Weblogic Domain node.
  3. 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.

  4. Right-click on the MFT server.

    For example, the MFT server might be mft_server1.

  5. Select Logs > View Log Messages.

    The Log Messages page appears.

  6. To display a list of MFT log files, click Target Log Files.

    The Log Files page appears.

  7. To View a log file, select the file and click View Log File.

    The View Log File page appears.

  8. To view specific types of messages, specify search criteria and click Search.

6.13 Managing Keystores using Oracle MFT Console

Keys and certificates are used to digitally sign and verify data and achieve authentication, integrity, and privacy in network communications. Use the Keystore Management tab on the Administration page to manage security keys using the Oracle Managed File Transfer console.

The Keystore Management tab presents the following tabs:

Keystores Tab

The Keystores tab lists the Default Keystore, PGP Keystore and SSH Keystore. Access to a keystore requires a password. See section Using Keystores Tab.

Keys Tab

Use the Keys tab to create, import, export, delete, and update SSH and PGP keys. The Keys tab lists the existing keys in the system. See section Using Keys Tab.

You can also use the Oracle WebLogic Scripting Tool (WLST) to manage keys as described in section Managing Keystores.

6.13.1 Using Keystores Tab

The Keystores tab lists the Default Keystore, PGP Keystore, and SSH Keystore. Access to a keystore requires a password which is defined at the time the keystore is created, by the person who creates the keystore, and which can only be changed by providing the current password.

In addition, each private key in a keystore can be secured by its own password.

Default Keystore

Oracle MFT uses SSL certificates for embedded server security to start Embedded FTPS server. The Default Keystore stores the SSL certificates. SSL certificate is used when there is an inbound transaction request when connecting to an embedded FTPS server. A private key and digital certificate provide identity for the server. The SSL certificates have private and public keys.

When logging in to external FTPS, you need to import the SSL certificate of remote FTPS server to SSL store to connect.

Enter the key password in the Private Key Password field if the SSL key is protected by a passphrase. Enter the store password in the Keystore Password field if the key store is protected by password.

For more information on creating SSL keys, refer section Configuring the SSL Keystore.

PGP Keystore

PGP keystore is used for encryption and decryption of the source and targets. The private keys are used to decrypt the payload and the public keys are used to encrypt the payload.

With the public key encryption, a public and a private key are generated for a server. Data encrypted with the public key can only be decrypted using the corresponding private key and vice-versa.

Enter the Private Key Password if the private key is protected by a passphrase.

Note:

The PGP Keystore supports only one private key password, you may have multiple private keys but the password to the private keys must be the same. 

SSH Keystore

Oracle MFT uses SSH keys for embedded SFTP server security. SSH keystore is used to store private and public keys.

For Embedded SFTP server, private SSH keys are used to start the embedded SFTP server and public keys are used to enable key based authentication to embedded SFTP server. To enable key based authentication for embedded SFTP server, you need to import the public key into SSH keystore and specify the Private key at the SSH client. While importing, the public key alias should be same as user name.

For remote SFTP server, private keys are used to authenticate to login to a remote server. The private key of the SSH key pair should be imported to MFT SSH store with any alias and alias should be chosen in the SFTP source/target and the public key will be shared with the remote SFTP server.

Enter the Private Key Password if the private key used for starting the SFTP server is protected by a passphrase.

6.13.2 Using Keys Tab

Use the Keys tab to create, import, export, delete, and update SSH and PGP keys. The Keys tab lists the existing keys in the system. You can search using the following filters:

  • Format: choose PGP, SSH, or All Types

  • Types of Keys: choose Private, Public, or All Types

You can also use the Oracle WebLogic Scripting Tool (WLST) to manage keys as described in section Managing Keystores.

Managing keys using the Keys tab

You can perform the following actions on the Keys tab:
6.13.2.1 Creating a Key

You can create a new key using the Keys tab on the Keystores Management page.

To create a key:
  1. From the Administration page, select Keystore Management.
  2. Select the Keys tab. You can search, create, update, export, import or delete a key.
  3. Click the Add + icon on the right side of the page to create a key. The Create key dialog opens.
  4. Enter the following details: Starred fields are required.
    • Alias: alias name

    • Format: select from PGP or SSH type of key

    • Key size: enter a valid integer between 1024 and 8192

    • Password: enter a password (optional)

    • Confirm Password: confirm the password (optional)

    • Identity: only if creating PGP key. Enter a default identity. For example an email ID.

    • Import Private Key: Check the box if importing a private key

  5. Click Create to create the key.
    A Download Key dialog appears with a link to download the generated key.
  6. Click the Download link to download the zip file containing the generated key.
6.13.2.2 Exporting a Key

Use the Keys tab in the Keystore Management to export the SSH or PGP keys.

To export a key:
  1. From the Administration page, select Keystore Management.
  2. Select the Keys tab. You can list, create, update, export, import or delete a key.
  3. Click the Export icon on the right side of the page. A window opens asking for the location to save the key file.
  4. Specify the download location and click Save.
    The key file is saved in the specified location.
6.13.2.3 Importing a Key

Use the Keys tab on the Keystore Management page to import SSH or PGP key.

To import a key:
  1. From the Administration page, select Keystore Management.
  2. Select the Keys tab. You can list, create, update, export, import or delete a key.
  3. Click the Import icon on the right side of the page.
    The Import key dialog opens.
  4. Enter the following details:
    • Alias: alias name

    • Format: select PGP or SSH type of key

    • Browse: enter the path of the key file

    • Type: specify private or public key

  5. Click Import to import the key. Or Cancel to cancel the action.
6.13.2.4 Updating a Key

Use the Keys tab in the Keystore Management page to update an existing PGP or SSH key.

To update an existing key:
  1. From the Administration page, select Keystore Management.
  2. Select the Keys tab. You can list, create, update, export, import or delete a key.
  3. Click the Update icon on the right side of the page to update a key.
  4. Enter the following details:
    • Alias: alias name

    • Browse: enter the path of the key file.

  5. Click Update to update the key. Or Cancel to cancel the action.
6.13.2.5 Deleting a Key

Use the Keys tab on the Keystore Management page to delete an existing PGP or SSH key.

To delete a key:
  1. From the Administration page, select Keystore Management.
  2. Select the Keys tab. You can list, create, update, export, import or delete a key.
  3. Click the Delete icon on the right side of the page. A confirmation message appears.
  4. Click OK to delete or No to cancel the action.

6.14 Incrementally Moving Oracle MFT Metadata with Configuration Plans

You can substitute key protocol attributes when you move MFT metadata from development or test environments to the production environment.

As you move metadata from one environment to another (for example, from testing to production), you may need to modify environment-specific values. Configuration plans enable you to modify these values using a single text (XML) file. The configuration plan can be created by using the export wlst command or by exporting it from the UI. The default generated configuration plan XML contains the current values. When you are ready to move the file to production you can modify the config plan xml to provide the substitute string for values that you want in the production environment. When calling the import command in the production system, you can optionally specify the modified config xml file to specify the string substitutions. To verify the modified configuration plan the previewMode option can be used. This option is available only in the wlst command not in the UI.

A new parameter, configFile has been added to the existing import wlst commands, which gives you the option to specify the string substitutions via a configPlan xml for key attributes.

Protocol Attributes

File

folder

FTP

host, controlPort, user, password, folder

SSH-FTP

host, port, user, password, folder, authenticationType, privateKeyFile, publicKeyFile

Embedded-FTP

folder

Embedded-SSH-FTP

folder

WS(SOA,SOAP,ODI,OSB)

url, service, port, action

B2B

tpChannelName

Healthcare

endpointName

Understanding When to Use Configuration Plans and T2P Migration

When you need to migrate data in MFT, you have two options, T2P migration or MFT Configuration Plans.

T2P is for one-time migration of whole deployments utilizing an MFT Plugin to the T2P Framework. The movement scripts are intended for moving to a new target environment. They do not support moving artifacts to an already existing environment nor do they allow moving artifacts incrementally.

For more information about the T2P migration scripts, see Moving from a Test to a Production Environment in Administering Oracle Fusion Middleware.

The MFT Config Plan is for incremental migration including artifact level properties (Sources, Targets, Transfers). You utilize the Config Plan in cases such as:

  • You need to migrate transfer1 from test to production and change the hostname from testHost1.com to partner1.com.

  • The password is different from one environment to another so the MFT Config Plan provides the option to change passwords during import

  • The PGP key alias is different from one environment to another so the MFT Config Plan provides the option to change key alias during import

Global Substitution for Attributes

You can globally substitute any of the attribute values apart from name or any internal field. The following are two examples of global string replacements:

<searchReplace>   

       <search>http://my-dev-server</search>    

      <replace>http://my-test-server</replace>    

  <searchReplace>
<Source name= "*">   

<searchReplace>       

   <search>http://my-dev-server1</search>        

   <replace>http://my-test-server1</replace>    

<searchReplace>

<Source>

Changing Key Attributes for a Given Source or Target

The ConfigPlan xml lists the key attributes for all the sources and targets and it provides the option to change the value for a specific artifact. For example:

<Source name="PO Source">  

<binding type="ftp">   

      <attribute name="port">    

             <replace>8888</replace>   

         </attribute>   

       <attribute name="host">   

             <replace>example.com</replace>     

        </attribute>   

</binding>

</Source>

In case of a conflict, the order of preference is:

  1. Artifact specific change

  2. Artifact specific global rule

  3. Global replacement

Basic validation is done for all substitution fields. Complete validation is done only during deployment. Basic validation includes:

  • Type validation : example only true/false will be allowed for Boolean fields

  • Restrictions check : if the field is bounded by certain specified values then only those values will be allowed

Specifying the Artifacts to Include in the Import

The config plan xml lets you specify the artifacts to include in the import. For example:

<transfers>

		<include>

				<transfer name="PO transfer"/>

		</include>

<transfers>

Password Change

A new wlst command createMftCredential returns and/or prints the CSF reference to the generated key. Once the key is generated in the target environment the same reference can be used in the config plan to replace the password fields.

Note:

Clear passwords are not supported.

Preview Imports

The preview mode option for the import command does not import metadata; it simply list the artifacts that will be exported and all attributes which will be overridden from the export zip because of the config plan. The default value is false.

Modified WLST Commands

Command Details Syntax and Parameters Examples

exportMetadata

Export (only TIP version) all the MFT metadata to given file 

exportMetadata('<ArchiveFile>', generateConfigPlan, longFormat)

ArchiveFile: File location for exporting metadata

generateConfigPlan(optional, default false): Indicates whether to generate the mftConfig XML. Config plan is generated in the same folder where archive file is generated

longFormat(optional, default false): If true, most of the attributes are included in the config plan xml; otherwise, only the key attributes are listed in the config plan XML

wls:/mydomain/serverConfig> exportMetadata("/tmp/mft/mds.zip") 
wls:/mydomain/serverConfig> exportMetadata("/tmp/mft/mds.zip", true)
wls:/mydomain/serverConfig> exportMetadata("/tmp/mft/mds.zip", true, true)

exportTransferMetadata

Export (only TIP version) the given transfer and related metadata to a given file.

exportTransferMetadata('<ArchiveFile>', '<TransferName>', generateConfigPlan, longFormat )

ArchiveFile: File location for exporting metadata

TransferName: Name of transfer to be exported

generateConfigPlan(optional, default false): Indicates whether to generate the mftConfig XML. Config plan is generated in the same folder where archive file is generated

longFormat(optional, default false): If true, most of the attributes are included in the config plan xml; otherwise, only the key attributes are listed in the config plan XML

wls:/mydomain/serverConfig> exportTransferMetadata('/tmp/mft/mds-xfer.zip', 'cotsmart-xfer')
wls:/mydomain/serverConfig> exportTransferMetadata('/tmp/mft/mds-xfer.zip', 'cotsmart-xfer', true)
wls:/mydomain/serverConfig> exportTransferMetadata('/tmp/mft/mds-xfer.zip', 'cotsmart-xfer', true, true)

exportDeployedArtifact

Export a deployed artifact from a given mds label.

exportDeployedArtifact('<ArtifactType>','<ArtifactName>',<Label>,'<ArchiveFilePath>',generateConfigPlan, longFormat) 

ArtifactType - SOURCE / TRANSFER / TARGET

ArtifactName: Name of the artifact to exported

Label: MDS label to be exported

ArchiveFilePath: File to which artifact is to be exported. It should be a zip file and should not exist.

generateConfigPlan(optional, default false): Indicates whether to generate the mftConfig XML. Config plan is generated in the same folder where archive file is generated

longFormat(optional, default false): If true, most of the attributes are included in the config plan xml; otherwise, only the key attributes are listed in the config plan XML

wls:/mydomain/serverConfig> exportDeployedArtifact('TARGET','cotsmart-file-tgt','soa_mft-2012-12-07 22:24:09.383','/tmp/export/cotsmart-file.zip')
wls:/mydomain/serverConfig> exportDeployedArtifact('TARGET','cotsmart-file-tgt','soa_mft-2012-12-07 22:24:09.383','/tmp/export/cotsmart-file.zip', true)
wls:/mydomain/serverConfig> exportDeployedArtifact('TARGET','cotsmart-file-tgt','soa_mft-2012-12-07 22:24:09.383','/tmp/export/cotsmart-file.zip', true,true)n

importMetadata

Import metadata from a given file location. Optionally mft config plan can be specified to change the parameter during import. Command can be run in preview mode as well.

importMetadata('<ArchiveFile>',<MftConfigPlanXML>, previewMode)

ArchiveFile: File location for importing metadata

configFileLocation(optional): File location for mftConfig XML

previewMode(optional, default false): If true, no metadata will be imported. It can be used to determine which attributes will be changed because of config plan.

wls:/mydomain/serverConfig> importMetadata("/tmp/mft/mds.zip")
wls:/mydomain/serverConfig> importMetadata("/tmp/mft/mds.zip","/tmp/mft/mftconfigplan.xml") 

This will import the metadata and override the values using the config plan XML.

wls:/mydomain/serverConfig> importMetadata("/tmp/mft/mds.zip","/tmp/mft/mftconfigplan.xml", false) 

It will not import the metadata. It provides info on which attributes will be changed using of config plan.

createMftCredential

Create the credential for mftapp.

createMftCredential(password, key) 

password: password for which credential needs to be created for mftapp.

key(optional) : key for the credential

wls:/mydomain/serverConfig> createMftCredential('mypass') 
wls:/mydomain/serverConfig> createMftCredential('mypass','mykey')

Related Topics

6.15 Adding a Purge Schedule

Use the Purge option from the Administration page to purge old instance and payload data from Oracle Managed File Transfer, thereby improving performance. The purge schedule is in addition to the seeded default purge.

You can purge data instantly or create a schedule to purge data. You can specify when to start and stop the purge, the frequency of the schedule purge and provide additional criteria to filter the instances to be purged. The criteria may include transfer status, transfer names, and the time range of the instances to be purged.

Note:

The Purge can be executed only by an admin user/administrator.

For information on creating a purge schedule, see Creating a New Purge Schedule.

For information on creating a Run Now purge, see Creating a Run Now Purge.

For information on modifying a purge schedule, see Modifying or Deleting an Existing Purge Schedule .

You can create or modify a purge schedule by using WLST commands. For more information, see MFT WLST Commands Summary.

6.15.1 Creating a New Purge Schedule

The Purge tab can be accessed from the Administration page. You can view the list of existing purge schedules. You can Create, Delete, Edit or Activate/Deactivate the purge schedule.

You can create an automated purge schedule to run at a predefined time and frequency. When purge schedule is executed at the scheduled date and time, the system will purge data that meets the filter criteria of status, transfer names and retention period.

Note:

The default Java Transaction API (JTA) time-out is 30 seconds, which is set in the Weblogic Admin console. Sometimes the purge operation may take more time to get executed based on data size and you may get a transaction time-out exception. To avoid exception errors, use the MBean property purgeTransactionTimeOut to modify the default JTA time-out for purge operation. See MFT WLST Command Summary for more information.
To add a new schedule purge:
  1. From the Administration page, select the Purge tab.
    You can view the Default Schedule and purge schedules created.
  2. Select the Add ‘+’ icon to create a new purge schedule.
    The Add Purge Schedule dialog opens.
  3. Specify the following details in the Add Purge schedule dialog:
    • Name - Specify a name for the schedule purge.

    • Schedule Start Date - The schedule start date.

    • Schedule End date (Optional) - The schedule end date on which the schedule stops. If the end date is not specified, the schedule will purge data continuously at the scheduled date and time.

    • Schedule Time - Specify the time when the purge starts. By default, it is set to 12 am.

    • Frequency - Specify the frequency of the schedule. Options are daily, weekly, monthly or yearly.

    • Retention Period - Specify the retention period for the old data in days. It specifies the time period of the instances that should not be included in the purge, it is calculated from the schedule run date. Default period is 7 days.

    • Status - Status of the instances that will be purged. Options - Completed and/or Failed. One of the options must be checked.

    • Transfer Filter - Name of transfer whose instance needs to be purged. If the Transfer name is not specified, the action would be applied to all instances for all transfers. When clicked, Select Transfer dialog appears where you can select the Transfer Names.

    • Comments - Provide comments.

  4. Select OK to continue or Cancel to cancel the action.
    A confirmation dialog opens.
  5. Select OK on the confirmation dialog.
    The newly created purge schedule is displayed in the list of Purge schedules with Next Execution Time and Activation Status as Active.

6.15.2 Creating a Run Now Purge

You can purge instance data immediately by selecting the Run Now option.

To create a Run Now Purge:
  1. From the Administration page, select the Purge tab.
  2. Select the Run Now tab.
    The Run Now dialog opens.
  3. Specify the following details in the Run Now dialog:
    • Retention Period - Specify the retention period of the old data in days. It specifies the time period of the instances that should be purged calculated from the schedule run date. Default period is 7 days.

    • Status - Status of the instances that will be purged. Options - Completed and/or Failed. One of the options must be checked.

    • Transfer Filter - Name of transfer whose instance needs to be purged. If the Transfer name is not specified, the action would be applied on all instances for all transfers. When clicked, Select Transfer dialog appears where you can select the Transfer Names. Select OK to continue.

    • Comments - (Optional) provide comment.

    • Execute - Select to execute the Purge.

    On execution, the instance data that meets the filter criteria is deleted immediately.

6.15.3 Modifying/Deleting an Existing Purge Schedule

You can modify or delete an existing purge schedule. To modify an active purge schedule, change the status to inactive and then modify the purge. However, if you edit an active schedule, a confirmation dialog opens up asking if you want to deactivate and edit the active schedule, click OK to continue.

You cannot edit the name of the purge schedule, all other details such as date, time, frequency, or retention period can be edited.

Note:

You cannot delete the Default Purge schedule or an active purge schedule.

If the selected purge schedule is in inactive status, you can delete, edit, or change the status. If the purge schedule is in active status, you can edit it only after changing the status to inactive.

When deactivating an active schedule, a confirmation message confirms if you want to go ahead with deactivation. Select OK to deactivate. This will disable the purge and change it to inactive status.

When you delete a schedule, it is removed from the list of purge schedules.