> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alumio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Common PCRE Expression

Reference walkthrough of the Common PCRE Expression example configuration: reusable regex-based cleanup, extraction, and validation patterns for transformer chains.

## Overview

This page documents an importable Data Integrator example configuration (`register.configuration.json`) named `[Example] - Common PCRE Expression` (identifier `example-common-pcre-expression`). It is not built to solve one specific integration; it is a reference snippet consultants can copy into a real flow and adapt.

<Note>
  The configuration is a plain `list-transformer` object, so it can be imported directly into an environment and inspected transformer-by-transformer in the flow builder.
</Note>

The chain starts with a `data` transformer containing a single `value-setter`. Each configuration entry pairs a sample input value with a `string-regex-replace` mapper, so the example doubles as a live preview of the pattern.

<Note>
  Alumio's regex mappers use **PCRE** syntax, not JavaScript regex. Patterns are wrapped in `/ /` delimiters and, unlike JavaScript, a match replaces **all** occurrences by default, no trailing `g` flag needed. Inline modifiers such as `(?i)` (case-insensitive) can be embedded directly in the pattern, as used in the country filter below.
</Note>

## String cleanup and extraction patterns

| Use Case                          | Sample input                           | Pattern (PCRE)           | Replacement | Result               |
| --------------------------------- | -------------------------------------- | ------------------------ | ----------- | -------------------- |
| Replace multiple spaces           | `Product        Name`                  | `/\s+/`                  | `" "`       | `Product Name`       |
| Mask an email address             | `john.doe@example.com`                 | `/^(.{2})[^@]*(@.*)$/`   | `$1***$2`   | `jo***@example.com`  |
| Remove HTML tags                  | `<p>Product <strong>Name</strong></p>` | `/<[^>]+>/`              | `" "`       | `" Product  Name  "` |
| Extract numeric value             | `Price: EUR 129.95`                    | `/.*?(\d+(?:\.\d+)?).*/` | `$1`        | `129.95`             |
| Extract order number              | `ORD-2026-000123`                      | `/^ORD-\d{4}-(\d+)$/`    | `$1`        | `000123`             |
| Remove non-alphanumeric character | `Product!@# Name #1`                   | `/[^A-Za-z0-9\s-]+/`     | `" "`       | `Product  Name  1`   |

<Warning>
  `remove_html_tags` and `remove_non_alphanumeric_characters` replace each matched run with a single space rather than collapsing whitespace afterward, so the result can contain doubled spaces (see the results above). In a real flow, chain the `replace_multiple_spaces` pattern afterward to normalize the output to single spaces.
</Warning>

## Filter use case: validation flags

| Use case                 | Pattern (PCRE)                                                                | Passes for                                |
| ------------------------ | ----------------------------------------------------------------------------- | ----------------------------------------- |
| Allow selected countries | `/(?i)^(NL\|BE\|DE\|FR)$/`                                                    | `NL`, `BE`, `DE`, `FR` (case-insensitive) |
| Validate email address   | `/^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$/`                          | A syntactically valid email address       |
| Validate EAN-13 barcode  | `/^\d{13}$/`                                                                  | Exactly 13 digits                         |
| Validate UUID            | `/^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/` | An RFC 4122 v1-v5 UUID (lowercase)        |

## Bundled test fixture

The configuration ships with a `transformer-test` fixture (`example-common-pcre-expression--sample-common-pcre-expression`) that runs the whole chain against one sample record:

```json theme={null}
{
  "uuid": "550e8400-e29b-41d4-a716-446655440000",
  "email": "john.doe@example.com",
  "country_code": "NL",
  "ean13_barcode": "8712345678901"
}
```

Against this sample record, all four validation flags evaluate to `true`. The fixture's `expected` field is left as an empty placeholder (`[[]]`) in the source example, so anyone copying this test should fill in the actual expected output for their adapted flow before relying on it as a regression test.