Configuring your actions

Yaml Action configuration basics

Yippee-Ki-JSON configuration files follow a simple structure. The main building blocks are:

1. Actions
2. Rules (and their parameters)
3. Functions/Suppliers/Predicates (and their parameters)

These are put together in the following format:

actions:
    # Action names must be unique for the file
  - name: "action-name"
    rules:
        # rule names must match the name of a registered
        # rule in the application
      - name: "rule-name-1"
        # A valid JSON Path 
        path: "$.json.path.expression"
      - name: "rule-name-2"
        path: "$.json.path.expression"
        # Additional parameters that are needed for the 
        # rule implementation
        params:
          param-name-1:
            # The name parameter can be used to resolve a 
            # registered Function/Supplier/Predicate
            name: "supplier-name"
            # Additional parameters needed to create a
            # Function/Supplier/Predicate for our rule
            value: "value"
          param-name-2:
            value: "$.can.be.anything"

What is an action?

An action is simply a named list of rules. Having a name is important to allow defining multiple kinds of transformation chains in a single file, and allowing the user to select between them using the relevant command line argument.

Each action can define a list of rules which will be applied one after the other in the order of their definition from top to bottom when we use the action.

What is a rule?

Each rule has the single purpose of transforming some parts of the input JSON denoted by the JsonPath that belongs to the rule. The action of transformation can come in many forms: it can add, rename, remove, replace, copy etc. parts of the document.

Do you want to find out more about the configuration details of our built-in rules we ship with the latest versions? Look no further than this page.

In case you can't seem to find the rule you need, you can try adding your own by taking a look at this page.

How do Functions/Suppliers/Predicates come into the picture?

From a flexibility point of view we find it advisable to implement rules with minimal baked-in functionality and allow their extension using Functions/Suppliers/Predicates. How does this work in practice? A good example is our replace rule which is using two parameters of this category. It has one Predicate which is used to decide whether we should do anything at all. By default, we are using the match any string predicate, but we could easily add any number of other Predicate implementations matching exactly the whole value, only the start etc without needing to implement a new rule. The second parameter we use for the aforementioned rule is a string replace Function that can do any kind of transformation to the existing value (in extreme cases without even taking a look at the old value). The built-in example implementation is a versatile, regular expression matching a replacing function.

In case you want to find out how to configure the existing implementations we offer? Check them out using the following links pointing to more information about functions, suppliers and predicates.

Not seeing what you need? Add new implementations to the growing number of registered Functions/Suppliers/Predicates by heading to our pages dedicated to functions, suppliers and predicates.