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:
-
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.
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:
-
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.
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:
-
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.
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:
-
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.
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:
-
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.
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 MFTExceptionQueue, 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.
-
Start WLST:
$MW_HOME/mft/common/bin/wlst.sh
-
Connect to MBean server:
connect("adminusername","adminpassword","t3://localhost:mft–port")where
mft–portis the configured port of the MFT server. -
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.
6.7.1 Configuring an Email Driver for 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:
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:
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:
|
|
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:
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:
-
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
soainfraorbase_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-handlerand 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.
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 |
|---|---|---|---|
|
|
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 |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
INFO |
SEVERE |
|
|
Not Applicable |
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 |
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:
6.13 Managing Keystores Using the Oracle Managed File Transfer 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 subtabs:
Keystores Tab
Keys Tab
The Keys tab lists the existing keys in the system. Use the Keys tab to manage SSH, PEM, and PGP keys. See Using the Keys Tab.
The PEM key format is available in 12c (12.2.1.4) only if you have installed patch 32395225. Additionally, to update the MFT Composer online help to reflect this change, you must install patch 32463347. Sign in to My Oracle Support and search for the patch numbers to locate and download the patches.
6.13.1 Using the Keystores Tab
The Keystores tab lists the Default Keystore, SSH Keystore, and PGP 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 (SSL) Keystore
Oracle MFT uses SSL certificates for embedded server security to start an embedded FTPS server. The default feystore stores the SSL certificates. An 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 an external FTPS, you must import the SSL certificate of the remote FTPS server to the SSL keystore to connect.
For steps to create the SSL keystore and keys using WLST commands and the Oracle Managed File Transfer console, see Configuring the SSL Keystore.
SSH Keystore
Oracle MFT uses SSH keys for embedded SFTP server security. The SSH keystore is used to store private and public keys.
For an 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 the embedded SFTP server. To enable key-based authentication for an embedded SFTP server, you must import the public key into the SSH keystore and specify the private key at the SSH client. While importing, the public key alias should be same as the user name.
For a remote SFTP server, private keys are used to authenticate to log in to a remote server. The private key of the SSH key pair should be imported to the SSH keystore with any alias and that alias must be selected in the SFTP source/target and the public key will be shared with the remote SFTP server.
For steps to create the SSH keystore and keys using WLST commands and the Oracle Managed File Transfer console, see Configuring the SSH Keystore.
PGP Keystore
The 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.
For steps to create the PGP keystore and keys using WLST commands and the Oracle Managed File Transfer console, see Configuring the PGP Keystore.
6.13.2 Using the Keys Tab
Use the Keys tab to create, import, export, delete, and update keys. The Keys tab lists the existing keys in the system.
You can filter the list of existing keys using the drop-down lists:
-
Format: select SSH, PEM, PGP, or All Formats.
-
Type: select Private, Public, or All Types. For an RSA key of PEM format, only Private is valid.
Note:
The PEM key format is available in 12c (12.2.1.4) only if you have installed patch 32395225. Additionally, to update the MFT Composer online help to reflect this change, you must install patch 32463347. Sign in to My Oracle Support and search for the patch numbers to locate and download the patches.
6.13.2.1 Creating a Key
You can create a new key using the Keys tab on the Keystores Management page.
Notes:
-
To generate a private RSA key of PEM format, which is used to connect to Oracle Cloud Infrastructure when the OCI Storage Cloud Service type is selected as a source or target, you cannot use the Oracle Managed File Transfer console or the WSLT
generateKeyscommand. Instead, you can use an external key generation application, such asssh-keygen, or follow the steps in How to Generate an API Signing Key in the Oracle Cloud Infrastructure documentation. Then, you can import the RSA key of PEM format.The OCI Storage Cloud Service type and the PEM key format is available in 12c (12.2.1.4) only if you have installed patch 32395225. Additionally, to update the MFT Composer online help to reflect this change, you must install patch 32463347. Sign in to My Oracle Support and search for the patch numbers to locate and download the patches.
- You can also use the Oracle WebLogic Scripting Tool (WLST) to
create a key. See
generateKeysin MFT WLST Command Summary.
To create a key:
- Click the Create Key
icon on the right side of the page to create a key.
6.13.2.2 Exporting a Key
You can export a key using the Keys tab on the Keystores Management page.
Note:
You can also use the Oracle WebLogic Scripting Tool (WLST) to export a key. SeeexportCSFKey in MFT WLST Command Summary.
To export a key:
- Click the Export Key
icon to the right of the key you want to export. Depending on your system settings, a window opens prompting you for the location to save the key file or the file is automatically downloaded to your Downloads directory.
6.13.2.3 Importing a Key
You can import a new key using the Keys tab on the Keystores Management page.
Notes:
-
Before you can use the OCI Storage Cloud Service type as a source or target, you must import a private RSA key of PEM format to connect to Oracle Cloud Infrastructure.
The OCI Storage Cloud Service type and the PEM key format is available in 12c (12.2.1.4) only if you have installed patch 32395225. Additionally, to update the MFT Composer online help to reflect this change, you must install patch 32463347. Sign in to My Oracle Support and search for the patch numbers to locate and download the patches.
- You can also use the Oracle WebLogic Scripting Tool (WLST) to import a key.
See
importCSFKeyin MFT WLST Command Summary.
To import a key:
- Click the Import Key
icon on the right side of the page. 
6.13.2.4 Updating a Key
You can update an existing key using the Keys tab on the Keystores Management page.
Note:
You can also use the Oracle WebLogic Scripting Tool (WLST) to update a key. SeeupdateCSFKey in MFT WLST Command Summary.
To update an existing key:
- Click the Update Key
icon to the right of the key you want to update.
6.13.2.5 Deleting a Key
You can delete an existing key using the Keys tab on the Keystores Management page.
Note:
You can also use the Oracle WebLogic Scripting Tool (WLST) to delete a key. SeedeleteCSFKey in MFT WLST Command Summary.
To delete a key:
- From the Administration page, select Keystore Management, then select the Keys tab.
- Click the Delete Key
icon to the right of the key you want to delete. - In the Confirm dialog, click Yes.
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:
-
Artifact specific change
-
Artifact specific global rule
-
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.
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 propertypurgeTransactionTimeOut to modify the default JTA time-out for purge operation. See MFT WLST Command Summary for more information.
6.15.2 Creating a Run Now Purge
You can purge instance data immediately by selecting the Run Now option.
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.