Before you import a packaged flow into a new environment, you may need to apply import rules to remap objects and locations from the source instance to the new instance. Import mapping rules are not required when importing into the same environment, although they may be helpful in some cases.
NOTE: Import mapping rules require the use of the APIs made available from the |
You can apply the following types of remappings:
Type | Description | |
---|---|---|
Value | For value remappings, you can specify rules to match on specific values or patterns of values in the import package and remap those values for use in the new instance.
| |
Object | For object remappings, you can specify rules to match a value listed in the import package and remap that value to a defined object in the new instance.
|
When a flow is imported, references in the flow definition that apply in the source instance may not apply in the target instance. For example, the location paths to the source datasets may need to be rewritten to point to a different location in the target instance.
Before you import your flow definition, you need to define rules for any value or object remapping that must be done in the target environment.
Value and object remapping rules should be completed before you import the flow definition. The flow may be non-functional until the rules are applied.
Tip: After you create your import rules, you can perform via API a dry run of the import. Any errors are reported in the response. Details are provided below. |
NOTE: Import mapping rules do not work for parameterized datasets. If the imported dataset with parameters is still accessible, you should be able to run jobs from it. |
The following are some example import rules to address specific uses.
In this following example, you must remap the connection from the source instance of the platform to the corresponding connection in the instance where you are importing.
First, you must be able to uniquely identify the connection from the source that you wish to remap.
In the API response in a connection definition, you can acquire the uuid
value for the connection, which is a unique identifier for the connection object across all instances of the platform:
Item | v3 APIs | |
---|---|---|
API Endpoint | From the source instance:
| |
Method |
| |
Request Body | None. | |
Response Body |
| |
Documentation | See API Connections Get v3. |
In the above, you identify that the connection used for the exported flow is the Postgres one. This object has the following unique identifier:
"uuid": "ae41c5a0-c460-11e7-8163-c3c02bb1fb0b" |
In the target system, you must now create a rule in the deployment into which you are importing that searches for this unique value. In the following example:
4
.1
.The uuid
field in the import package is searched for the matching string. If it is found, the connection in the import package is replaced with the connection in the target system with an Id of 1
:
Item | v3 APIs | |
---|---|---|
API Endpoint |
| |
Method |
| |
Request Body |
| |
Status Code - Success | 200 - OK | |
Response Body | When the new rules are applied, all previously existing rules for the object in the deployment are deleted. The response body contains any rules that have been deleted as part of this request. In the following example, there were no rules, so nothing was deleted:
| |
Documentation | See API Deployments Object Import Rules Patch v3. |
To test your rule, perform a dry run of the import. See below.
In this example, your import rule must remap the path to the source from your Dev paths to your Prod paths. Suppose the pattern looks like this:
Dev Path | hdfs://datasets/dev/1/164e0bca-8c91-4e3c-9d0a-2a85eedec817/myData.csv |
---|---|
Prod Path | hdfs://datasets/prod/1/164e0bca-8c91-4e3c-9d0a-2a85eedec817/myData-Prod.csv |
Note the differences:
/dev/
part of the path has been replaced by /prod/
.You can use the following value import rules to change the path values. In the following example, the rules are applied separately.
NOTE: You can specify multiple rules in a single request. Rules are applied in the order that they are listed. Latter rules must factor the results of earlier rules. |
Item | v3 APIs | |
---|---|---|
API Endpoint |
| |
Method |
| |
Request Body |
| |
Status Code - Success | 200 - OK | |
Response Body | When the new rules are applied, all previously existing rules for the object in the deployment are deleted. The response body contains any rules that have been deleted as part of this request. In the following example, there were no rules, so nothing was deleted:
| |
Documentation | See API Deployments Value Import Rules Patch v3. |
To test your rule, perform a dry run of the import. See below.
For S3 sources, you can apply remapping rules including changing to a new S3 bucket.
In this example, your import rule must remap the path to the source from your Dev paths to your Prod paths. Suppose the pattern looks like this:
Dev S3 Bucket Name | wrangle-dev |
---|---|
Dev Path | /projs/tweets/v04/tweets_month.csv |
Prod S3 Bucket Name | wrangle-prod |
Prod Path | /tweets/tweets_month.csv |
You can use the following value import rules to change the bucket name and path values.
NOTE: You can specify multiple rules in a single request. Rules are applied in the order that they are listed. Latter rules must factor the results of earlier rules. |
s3Bucket name rule: This rule replaces the name of the S3 bucket to use with the new one: wrangle-prod
.
fileLocation rule: This rule uses regular expressions to match each segment of the path in the source bucket's paths.
Item | v3 APIs | |
---|---|---|
API Endpoint |
| |
Method |
| |
Request Body |
| |
Status Code - Success | 200 - OK | |
Response Body | When the new rules are applied, all previously existing rules for the object in the deployment are deleted. The response body contains any rules that have been deleted as part of this request. In the following example, there were no rules, so nothing was deleted:
| |
Documentation | See API Deployments Value Import Rules Patch v3. |
To test your rule, perform a dry run of the import. See below.
After you have specified a set of import rules, you can perform a dry-run of an import of an import package. This dry-run does not perform the actual import but does report any permissions errors or other issues in the response.
In this example, the flow2import.zip
file contains the package to import into deployment 4
.
Item | v3 APIs | ||||
---|---|---|---|---|---|
API Endpoint |
| ||||
Method |
| ||||
Request Body | In form data submitted with the request, you must include the following key-value pair:
| ||||
Status Code - Success | 200 - OK | ||||
Response Body | The response body contains any import remapping rules that have been applied during the import process.
| ||||
Documentation | See API Releases Create DryRun v3. |
After the above dry-run has been executed, the import package can be imported and is automatically connected to the appropriate connection. See API Releases Create v3.