Content Gateway supports a feature called "Metadata metadata transformation" it , which is to put simply a set of rules which will add that adds custom metadata to every object in a domain or bucket.
The feature is documented
here
https://connect.caringo.com/system/files/docs/s10/Gateway_Metadata_Transformation.html
and here
https://connect.caringo.com/system/files/docs/s10/Defined_ETC_Documents.htmldocumented here:
The feature is used in conjunction with the management api + scsp Management API and SCSP on the content gateway Content Gateway, and has been available since Gateway version 3.
Instructions
...
Designing the metadata
Use XForm documents when you need to apply certain metadata to all objects in a domain or all objects in a bucket (depending on where the xform document is appliedyou apply them).
The xform XForm document by itself is a json JSON document which that defines the custom metadata.At At its simplest, the doc document would look something like this.
{
| Code Block | ||
|---|---|---|
| ||
{ "metadata": { |
...
"X-Color-Meta": "blue" |
...
} |
...
} |
...
xform.json (END) |
This form would apply the metadata X-Color-Meta : blue to every file uploaded to a bucket or domain.
A more useful usecase may practical use case would be to add a company id identifier or tag for situations where multiple tenants share a cluster.
| Code Block | ||
|---|---|---|
| ||
{ |
...
"metadata": { |
...
"X-Company-Meta": |
...
}
}
"MetaCorp, Inc." } } xform.json (END) |
While assigning static metadata can be useful there are a few dynamic pieces of metadata you can assign also., you can make use of several variables:
Variable Name | Description |
| Create/update time stamp where format is defined by Java SimpleDateFormat specification |
|---|---|
| Authenticated user ID |
| Domain name |
| Bucket name |
As in the documented example below this Using these can result in some very useful applications. For example the json below
{ "comments": "Metadata transform document",:
| Code Block | ||
|---|---|---|
| ||
{ "metadata": { |
...
"X-Written-When-Meta": "${date:yyyyMMdd-HHmmss}", |
...
"X-Contains-Meta": "${domain}/${bucket}", |
...
"X-Copyright-Meta": "Copyright ${date:yyyy}, MetaCorp, Inc", |
...
"X-Author-Meta": "${user}" |
...
} |
...
} |
Will result in the highlighted extra metadata on This JSON causes any file uploaded to the domain .
to have the additional metadata highlighted below:
Installing the XForm
To use the feature first create the xform.json , upload your XForm document with the correct method and headers:
- Create the XForm file with the definitions
...
- for your custom metadata
...
- , described above.
- Important: Validate the syntax of the JSON you are applying. Use a JSON validator such as https://jsonlint.com.
- Save it as
xform.jsonor
...
- similar.
...
...
- Verify that the user that will upload to the
...
- Gateway has the permissions on their policy to be able to PUT a policy or GET a policy.
...
- The XForm is an
/etcdocument
...
- , which you upload via the management API using the /_admin/manage path:
...
- If your Gateway IP is 10.0.0.10
...
- , the starting URL is
http://10.0.0.10/_admin/manage
- , the starting URL is
...
- If your Gateway resolves from cloud.example.com
...
- , the starting URL is
http://cloud.example.com/_admin/manage/
- , the starting URL is
...
- To etc documents in a tenant
...
- , use this form (see Namespace Structure):
http://cloud.example.com/_admin/manage/tenants/{tenantname}/etc/{insertyourjson}
This is described in this section of the docs
https://connect.caringo.com/system/files/docs/s10/Namespace_Structure.html
...
The application of the
...
XForm metadata doc is a
...
HTTP PUT, shown here as cURL:
Code Block language bash curl -X PUT --data-binary @xformcorp.json -u tlokko -H "Content-Type: application/json" https://cloud.example.com/_admin/manage/tenants/cloud/domains/
...
d1.cloud.example.com/etc/metaxform.json
So if we break the below down.Usage:
curl -X PUT |
...
| The HTTP verb to |
...
| PUT an object |
--data-binary @xformcorp.json |
...
| Specifies reading the body of the xformcorp.json from a local file |
...
-u tlokko |
...
| Specifies the user |
...
| that will PUT the file (must have that policy permission) | |
-H "Content-Type: application/json" | Required: This is a custom header for the file, and it is very important |
...
: If this content type isn't there |
...
, Gateway will fail to read the contents of the |
...
JSON correctly and writes to the |
...
Gateway may fail. |
https://cloud.example.com/_admin/manage/ |
management uri
...
| The Management API URI | |
...tenants/cloud/ | The base tenant |
...
.. |
...
. |
...
domains/ |
...
d1.cloud.example.com/ |
...
| The domain we're applying it to |
...
.. |
...
. |
...
domains/ |
...
d1.cloud.example.com/etc/metaxform.json |
...
| The end filename |
...
if we wanted to be more selective and apply it at the bucket level we would go one level deeper
...
...domains/d1.cloud.example.com/buckets/ |
...
b1/etc/metaxform.json |
**important notes.
double and triple check the syntax of the json you are applying if you are applying a metadata transformation to a domain level object.
I recommend using a json validator when trying this stuff out https://jsonlint.com/ is a good one.
Be sure to add the "Content-Type: application/json" to the etc doc when uploading.
There is a precedence model in play here , any domain level xform.json will supersede a bucket level one.
...
Applies it only at the bucket level
|
Related articles
| Filter by label (Content by label) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Page Properties | ||
|---|---|---|
| ||
|