

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Policy di filtro degli abbonamenti Amazon SNS
<a name="sns-subscription-filter-policies"></a>

Una policy di filtro per le sottoscrizioni consente di specificare nomi di proprietà e di assegnare un elenco di valori a ciascuno di questi nomi. Per ulteriori informazioni, consulta [Filtraggio messaggi di Amazon SNS](sns-message-filtering.md).

Quando Amazon SNS valuta gli attributi del messaggio o le proprietà del corpo del messaggio rispetto alla policy di filtro per le sottoscrizioni, ignora quelli non specificati nella policy.

**Importante**  
AWS servizi come IAM e Amazon SNS utilizzano un modello di calcolo distribuito chiamato eventuale consistenza. Le aggiunte o le modifiche a una policy di filtro sottoscrizione richiedono fino a 15 minuti per essere pienamente effettive. 

Una sottoscrizione accetta un messaggio nelle seguenti condizioni:
+ Quando l'ambito della policy di filtro è impostato su `MessageAttributes`, ogni nome di proprietà nella policy di filtro corrisponde al nome dell'attributo del messaggio. Per ogni nome di proprietà corrispondente nella policy di filtro, almeno un valore di proprietà corrisponde al valore dell'attributo del messaggio.
+ Quando l'ambito della policy di filtro è impostato su `MessageBody`, ogni nome di proprietà nella policy di filtro corrisponde al nome della proprietà del corpo del messaggio. Per ogni nome di proprietà corrispondente nella policy di filtro, almeno un valore di proprietà corrisponde al valore della proprietà del corpo del messaggio.

Attualmente Amazon RDS supporta i seguenti operatori di filtro:
+ [Logica AND](and-or-logic.md#and-logic)
+ [Logica OR](and-or-logic.md#or-logic)
+ [Operatore OR](and-or-logic.md#or-operator)
+ [Corrispondenza di chiave](attribute-key-matching.md)
+ [Corrispondenza esatta dei valori numerici](numeric-value-matching.md#numeric-exact-matching)
+ [Corrispondenza Anything-but dei valori numerici](numeric-value-matching.md#numeric-anything-but-matching)
+ [Corrispondenza intervallo dei valori numerici](numeric-value-matching.md#numeric-value-range-matching)
+ [Corrispondenza esatta dei valori di stringa](string-value-matching.md#string-exact-matching)
+ [Corrispondenza Anything-but delle stringhe](string-value-matching.md#string-anything-but-matching)
+ [Corrispondenza di stringhe utilizzando un prefisso con l'operatore anything-but](string-value-matching.md#string-anything-but-matching)
+ [equals-ignore case dei valori di stringa](string-value-matching.md#string-equals-ignore)
+ [Corrispondenza dell'indirizzo IP dei valori di stringa](string-value-matching.md#string-address-matching)
+ [Corrispondenza del prefisso dei valori di stringa](string-value-matching.md#string-prefix-matching)
+ [Corrispondenza del suffisso dei valori di stringa](string-value-matching.md#string-suffix-matching)

# Esempi di politiche di filtro di Amazon SNS
<a name="example-filter-policies"></a>

L'esempio seguente mostra un payload di messaggio inviato da un argomento Amazon SNS che elabora transazioni di clienti.

Il primo esempio include il campo `MessageAttributes`, che presenta attributi che descrivono la transazione:
+ Interessi del cliente
+ Nome dello store
+ Stato dell'evento
+ Prezzo di acquisto in USD

Poiché questo messaggio include il campo `MessageAttributes`, qualsiasi sottoscrizione all'argomento che imposta un `FilterPolicy` può accettare o rifiutare in modo selettivo il messaggio, a condizione che `FilterPolicyScope` sia impostato su `MessageAttributes` nella sottoscrizione. Per informazioni sull'applicazione di attributi a un messaggio, consulta [Attributi messaggio di Amazon SNS](sns-message-attributes.md).

```
{
   "Type": "Notification",
   "MessageId": "a1b2c34d-567e-8f90-g1h2-i345j67klmn8",
   "TopicArn": "arn:aws:sns:us-east-2:123456789012:MyTopic",
   "Message": "message-body-with-transaction-details",
   "Timestamp": "2019-11-03T23:28:01.631Z",
   "SignatureVersion": "4",
   "Signature": "signature",
   "UnsubscribeURL": "unsubscribe-url",
   "MessageAttributes": {
      "customer_interests": {
         "Type": "String.Array",
         "Value": "[\"soccer\", \"rugby\", \"hockey\"]"
      },
      "store": {
         "Type": "String",
         "Value":"example_corp"
      },
      "event": {
         "Type": "String",
         "Value": "order_placed"
      },
      "price_usd": {
         "Type": "Number", 
         "Value": "210.75"
      }
   }
}
```

L'esempio seguente mostra gli stessi attributi inclusi nel campo `Message`, denominato anche *payload del messaggio* o *corpo del messaggio*. Qualsiasi sottoscrizione a un argomento che includa un `FilterPolicy` può accettare o rifiutare in modo selettivo il messaggio, a condizione che `FilterPolicyScope` sia impostato su `MessageBody` nella sottoscrizione. 

```
{
"Type": "Notification",
   "MessageId": "a1b2c34d-567e-8f90-g1h2-i345j67klmn8",
   "TopicArn": "arn:aws:sns:us-east-2:123456789012:MyTopic",
   "Message": "{
      \"customer_interests\": [\"soccer\", \"rugby\", \"hockey\"],
      \"store\": \"example_corp\",
      \"event\":\"order_placed\",
      \"price_usd\":210.75
   }",
   "Timestamp": "2019-11-03T23:28:01.631Z",
   "SignatureVersion": "4",
   "Signature": "signature",
   "UnsubscribeURL": "unsubscribe-url"
}
```

Le seguenti policy di filtro accettano o rifiutano i messaggi in base ai relativi nomi e valori delle proprietà.

## Policy che accetta il messaggio di esempio
<a name="policy-accepts-messages"></a>

Le proprietà nella seguente policy di filtro per le sottoscrizioni corrispondono a quelli assegnati al messaggio di esempio. È importante notare che la stessa policy di filtro funziona per un `FilterPolicyScope` indipendentemente dal fatto che sia impostata su `MessageAttributes` o su `MessageBody`. Ogni sottoscrittore sceglie il proprio ambito di filtro in base alla composizione dei messaggi che riceve dall'argomento.

Se una singola proprietà specificata in questa policy non corrisponde a un attributo assegnato al messaggio, la policy rifiuta il messaggio.

```
{
   "store": ["example_corp"],
   "event": [{"anything-but": "order_cancelled"}],
   "customer_interests": [
      "rugby",
      "football",
      "baseball"
   ],
   "price_usd": [{"numeric": [">=", 100]}]
}
```

## Policy che rifiuta il messaggio di esempio
<a name="policy-rejects-messages"></a>

La policy seguente presenta diverse mancate corrispondenze tra le sue proprietà e quelle assegnate al messaggio di esempio. Ad esempio, poiché il nome della proprietà `encrypted` non figura fra gli attributi del messaggio, tale proprietà della policy causa il rifiuto del messaggio, indipendentemente dal valore a esso assegnato. 

Se si verifica una qualsiasi mancata corrispondenza, la policy rifiuta il messaggio.

```
{
   "store": ["example_corp"],
   "event": ["order_cancelled"],
   "encrypted": [false],
   "customer_interests": [
      "basketball",
      "baseball"
   ]
}
```

# Filtra i vincoli delle policy in Amazon SNS
<a name="subscription-filter-policy-constraints"></a>

Quando configuri le politiche di filtro in Amazon SNS, ci sono alcune regole importanti da tenere a mente. Queste regole aiutano a garantire l'applicazione efficace delle politiche di filtro mantenendo al contempo le prestazioni e la compatibilità del sistema.

## Vincoli comuni delle policy
<a name="subscription-filter-policy-common-constraints"></a>

Quando configuri le politiche di filtro in Amazon SNS, segui queste importanti regole per assicurarti che funzionino in modo efficace mantenendo le prestazioni e la compatibilità del sistema:
+ **Corrispondenza delle stringhe**: per la corrispondenza delle stringhe nella politica di filtro, il confronto fa distinzione tra maiuscole e minuscole.
+ **Corrispondenza numerica**: per la corrispondenza numerica, il valore può variare da -10 9 a 10 9 (da -1 miliardo a 1 miliardo), con una precisione di cinque cifre dopo la virgola decimale.
+ **Complessità della politica di filtro****: la combinazione totale di valori in una politica di filtro non deve superare 150.** Per calcolare la combinazione totale, moltiplica il numero di valori in ogni array nella politica di filtro.
+ **Limita il numero di chiavi**: una politica di filtro può avere un massimo di **cinque** chiavi.

****Considerazioni aggiuntive****
+ Il JSON della policy di filtro può contenere quanto segue:
  + Stringhe tra virgolette
  + Numeri
  + Le parole chiave `true`, `false` e `null` senza virgolette
+ **Quando usi l'API Amazon SNS, devi passare il codice JSON della policy di filtro come stringa UTF-8 valida.**
+ **La dimensione massima di una policy di filtro è 256 KB.**
+ Per impostazione predefinita, puoi avere fino a **200** politiche di filtro per argomento e **10.000** politiche di filtro per AWS account.

  Questo limite di policy non impedirà la creazione di abbonamenti alla coda Amazon SQS con l'API. [https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html](https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html) Tuttavia, l'operazione avrebbe esito negativo quando si collega la policy di filtro alla chiamata API `Subscribe` (o alla chiamata API [https://docs.aws.amazon.com/sns/latest/api/API_SetSubscriptionAttributes.html](https://docs.aws.amazon.com/sns/latest/api/API_SetSubscriptionAttributes.html)).

  Per richiedere un aumento della quota, è possibile utilizzare [AWS Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html).

## Vincoli delle policy per il filtro basato sugli attributi
<a name="subscription-filter-policy-attribute-constraints"></a>

Il filtro basato sugli attributi è l'opzione predefinita. [https://docs.aws.amazon.com/sns/latest/api/API_SetSubscriptionAttributes.html#API_SetSubscriptionAttributes_RequestParameters](https://docs.aws.amazon.com/sns/latest/api/API_SetSubscriptionAttributes.html#API_SetSubscriptionAttributes_RequestParameters) è impostato su `MessageAttributes` nella sottoscrizione.
+ Amazon SNS non accetta una policy di filtri annidati per il filtro basato su attributi.
+ Amazon SNS confronta le proprietà della policy solo con gli attributi di messaggio che hanno i seguenti tipi di dati:
  + `String`
  + `String.Array`
**Importante**  
Quando si utilizza il filtro basato sugli attributi in Amazon SNS, è necessario eseguire il doppio escape di determinati caratteri speciali, in particolare:  
Virgolette doppie («)
Barre rovesciate ()
Se non si esegue il double escape di questi caratteri, la politica di filtro non corrisponderà agli attributi di un messaggio pubblicato e la notifica non verrà recapitata.

**Considerazioni aggiuntive**
+ Il passaggio di oggetti negli array non è consigliato perché potrebbe produrre risultati imprevisti a causa della nidificazione, che non è supportata dal filtraggio basato sugli attributi. Utilizzo del filtraggio basato sul payload per le policy nidificate.
+ `Number`è supportato per i valori degli attributi numerici.
+ Amazon SNS ignora gli attributi dei messaggi con il tipo di dati binario.

**Esempio di politica di complessità:**

Nel seguente esempio di policy, la prima chiave ha **tre** operatori di corrispondenza, la seconda ha **un** operatore di corrispondenza e la terza ha **due** operatori di corrispondenza.

```
{
   "key_a": ["value_one", "value_two", "value_three"],
   "key_b": ["value_one"],
   "key_c": ["value_one", "value_two"]
}
```

La combinazione totale viene calcolata come il prodotto del numero di operatori di corrispondenza per ogni chiave nella politica di filtro:

```
3(match operators of key_a) 
x 1(match operators of key_b) 
x 2(match operators of key_c) 
= 6
```

## Vincoli delle policy per il filtro basato su payload
<a name="subscription-filter-policy-payload-constraints"></a>

Per passare dal filtro basato sugli attributi (predefinito) al filtro basato sul payload, è necessario impostare [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeprovisionIpamPoolCidr.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeprovisionIpamPoolCidr.html) su `MessageBody` nella sottoscrizione.
+ Amazon SNS accetta una policy di filtri annidati per il filtro basato su payload.
+ Per una politica annidata, solo **le chiavi a foglia** vengono conteggiate per il limite di **cinque** chiavi.

**Esempio di politica per il limite delle chiavi:**

Nel seguente esempio di politica:
+ Ci sono due tasti a forma di foglia: `key_c` e`key_e`.
+ `key_c`**ha **quattro** operatori di corrispondenza con un livello nidificato di **tre** e `key_e` dispone di **tre** operatori di corrispondenza con un livello nidificato di due.**

```
{
"key_a": {
    "key_b": {
        "key_c": ["value_one", "value_two", "value_three", "value_four"]
        }
    },
"key_d": {
    "key_e": ["value_one", "value_two", "value_three"]
    }
}
```

La combinazione totale viene calcolata come il prodotto del numero di operatori di corrispondenza e del livello annidato per ciascuna chiave nella politica di filtro:

```
4(match operators of key_c) 
x 3(nested level of key_c) 
x 3(match operators of key_e) 
x 2(nested level of key_e) 
= 72
```

## Linee guida per l'utilizzo del pattern Wildcard
<a name="filter-policy-constraints-wildcard"></a>

 Amazon SQS implementa protezioni quando registri una policy di filtro contenente wildcard per garantire che non vengano create policy di filtro troppo complesse, poiché ciò influirebbe sulle prestazioni dell'applicazione. 

**Struttura del pattern**

I campi contengono uno o più motivi. L'esempio seguente mostra un campo che utilizza due modelli:

```
{
    "greeting": [
      {"anything-but": {"prefix": "Hello"}},
      {"wildcard": "H*"}
    ] // 2 patterns
  }
```

**Regole di complessità**
+  La complessità totale dei caratteri jolly in tutti i campi non deve superare i 100 punti 
+  Massimo 3 caratteri jolly per pattern 

**Calcolo della complessità**
+  Complessità del campo = `(Sum of pattern points)` × `(Number of patterns)` 
+ Punti del modello:

   Wild card singola: 1 punto 

   jolly multipli: 3 punti ciascuno 

   Tutto tranne: 1 punto 

  Di seguito è riportato un esempio di calcolo della complessità:

  ```
  {
    "filename": [
      {"wildcard": "*.txt"},     // 1 point
      {"wildcard": "log*"}      // 1 point
    ]                           // Total: (1 + 1) × 2 = 4 points
  }
  ```

# Logica AND/OR
<a name="and-or-logic"></a>

Usa AND/OR la logica nelle politiche di filtro per abbinare gli attributi o le proprietà del corpo del messaggio in Amazon SNS. Ciò consente un filtraggio dei messaggi più preciso e flessibile.

## Logica AND
<a name="and-logic"></a>

Puoi applicare l'operatore logico AND utilizzando più nomi di proprietà.

Esaminiamo la seguente policy:

```
{
  "customer_interests": ["rugby"],
  "price_usd": [{"numeric": [">", 100]}]
}
```

Corrisponde a qualsiasi attributo di messaggio o corpo del messaggio che abbia il valore di `customer_interests` impostato su `rugby` *e* il valore di `price_usd` impostato su un numero superiore a 100.

**Nota**  
Non è possibile applicare la logica AND ai valori dello stesso attributo.

## Logica OR
<a name="or-logic"></a>

Puoi applicare l'operatore logico OR assegnando più valori a un nome di proprietà.

Esaminiamo la seguente policy:

```
{
   "customer_interests": ["rugby", "football", "baseball"]
}
```

Corrisponde a qualsiasi attributo di messaggio o proprietà del corpo di messaggio con il valore di `customer_interests` impostato su `rugby`, `football` *o* `baseball`.

## Operatore OR
<a name="or-operator"></a>

È possibile utilizzare l'operatore `"$or"` per definire in modo esplicito una policy di filtro per esprimere la relazione OR tra più attributi della policy.

Amazon SNS riconosce una relazione `"$or"` solo quando la policy soddisfa tutte le seguenti condizioni. Se tutte queste condizioni non sono soddisfatte, `"$or"` viene considerato come un normale nome di attributo, come qualsiasi altra stringa della policy.
+ Nella regola seguita da un array è presente un attributo di campo `"$or"`, ad esempio, `“$or” : []`.
+ Ci sono almeno 2 oggetti nell'array `"$or"`: `"$or": [{}, {}]`.
+ Nessuno degli oggetti nell'array `"$or"` ha nomi di campo che sono parole chiave riservate.

Altrimenti `"$or"` viene considerato come un normale nome di attributo, come le altre stringhe della policy.

La seguente policy non viene analizzata come una relazione OR perché numerico e prefisso sono parole chiave riservate.

```
{ 
   "$or": [ {"numeric" : 123}, {"prefix": "abc"} ] 
}
```

**Esempi di operatori `OR`**

`OR` standard:

```
{
  "source": [ "aws.cloudwatch" ], 
  "$or": [
    { "metricName": [ "CPUUtilization" ] },
    { "namespace": [ "AWS/EC2" ] }
  ] 
}
```

La logica di filtro per questa policy è:

```
"source" && ("metricName" || "namespace")
```

Corrisponde a uno dei seguenti set di attributi di messaggio:

```
"source": {"Type": "String", "Value": "aws.cloudwatch"},
"metricName": {"Type": "String", "Value": "CPUUtilization"}
```

or

```
"source": {"Type": "String", "Value": "aws.cloudwatch"},
"namespace": {"Type": "String", "Value": "AWS/EC2"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
    "source": "aws.cloudwatch",
    "metricName": "CPUUtilization"
}
```

or

```
{
    "source": "aws.cloudwatch",
    "namespace": "AWS/EC2"
}
```

### Vincoli della policy che includono le relazioni `OR`
<a name="or-operator-constraints"></a>

Esaminiamo la seguente policy:

```
{
    "source": [ "aws.cloudwatch" ],
    "$or": [
      { "metricName": [ "CPUUtilization", "ReadLatency" ] },
      {
        "metricType": [ "MetricType" ] ,
        "$or" : [
          { "metricId": [ 1234, 4321 ] },
          { "spaceId": [ 1000, 2000, 3000 ] }
        ]
      }
    ]
  }
```

La logica di questa policy può anche essere semplificata come segue:

```
("source" AND "metricName") 
OR 
("source" AND "metricType" AND "metricId") 
OR 
("source" AND "metricType" AND "spaceId")
```

Il calcolo della complessità per le policy con relazioni OR può essere semplificato come somma delle complessità di combinazioni per ogni istruzione OR.

La combinazione totale si calcola nel seguente modo:

```
(source * metricName) + (source * metricType * metricId) + (source * metricType * spaceId)
= (1 * 2) + (1 * 1 * 2) + (1 * 1 * 3) 
= 7
```

`source` ha un valore, `metricName` ha due valori, `metricType` ha un valore, `metricId` ha due valori e `spaceId` ha tre valori.

Considera la seguente policy di filtro nidificata:

```
{
    "$or": [
      { "metricName": [ "CPUUtilization", "ReadLatency" ] },
      { "namespace": [ "AWS/EC2", "AWS/ES" ] }
    ],
    "detail" : {
      "scope" : [ "Service" ],
      "$or": [
        { "source": [ "aws.cloudwatch" ] },
        { "type": [ "CloudWatch Alarm State Change"] }
      ]
    }
  }
```

La logica di questa policy può essere semplificata come segue:

```
("metricName" AND ("detail"."scope" AND "detail"."source")
OR
("metricName" AND ("detail"."scope" AND "detail"."type")
OR
("namespace" AND ("detail"."scope" AND "detail"."source")
OR
("namespace" AND ("detail"."scope" AND "detail"."type")
```

Il calcolo per le combinazioni totali è lo stesso per le policy non nidificate, tranne per il fatto che è necessario considerare il livello di nidificazione di una chiave.

La combinazione totale si calcola nel seguente modo:

```
(2 * 2 * 2) + (2 * 2 * 2) + (2 * 2 * 2) + (2 * 2 * 2) = 32
```

`metricName` ha due valori, `namespace` ha due valori, `scope` è una chiave nidificata a due livelli con un valore, `source` è una chiave nidificata a due livelli con un valore e `type` è una chiave nidificata a due livelli con un valore.

# Corrispondenza di chiave
<a name="attribute-key-matching"></a>

Utilizza l'`exists`operatore in una politica di filtro per abbinare i messaggi in arrivo a seconda che una proprietà specifica sia presente o assente.
+ `exists`funziona solo sui nodi foglia (attributi finali della struttura).
+ Non si applica ai nodi intermedi all'interno di una struttura JSON annidata.
+ Utilizza `"exists": true` per creare corrispondenze con i messaggi in arrivo che includono la proprietà specificata. La chiave deve avere un valore non null e non vuoto.

  Ad esempio, la seguente proprietà di policy utilizza l'operatore `exists` con un valore di `true`:

  ```
  "store": [{"exists": true}]
  ```

  Corrisponde a qualsiasi elenco di attributi di messaggi contenente la chiave attributo `store`, ad esempio:

  ```
  "store": {"Type": "String", "Value": "fans"}
  "customer_interests": {"Type": "String.Array", "Value": "[\"baseball\", \"basketball\"]"}
  ```

  Corrisponde anche a uno dei seguenti corpi di messaggi:

  ```
  {
      "store": "fans"
      "customer_interests": ["baseball", "basketball"]
  }
  ```

  Tuttavia, non corrisponde a nessun elenco di attributi di messaggi *senza* la chiave attributo `store`, ad esempio:

  ```
  "customer_interests": {"Type": "String.Array", "Value": "[\"baseball\", \"basketball\"]"}
  ```

  Né corrisponde al seguente corpo del messaggio:

  ```
  {
      "customer_interests": ["baseball", "basketball"]
  }
  ```
+ Utilizza `"exists": false` per creare corrispondenze con i messaggi in arrivo che *non* includono la proprietà specificata.
**Nota**  
`"exists": false` genera corrispondenze solo se è presente almeno un attributo. Un set vuoto di attributi non consente al filtro di generare corrispondenze.

  Ad esempio, la seguente proprietà di policy utilizza l'operatore `exists` con un valore di `false`:

  ```
  "store": [{"exists": false}]
  ```

  *Non* corrisponde a nessun elenco di attributi di messaggi contenente la chiave attributo `store`, ad esempio:

  ```
  "store": {"Type": "String", "Value": "fans"}
  "customer_interests": {"Type": "String.Array", "Value": "[\"baseball\", \"basketball\"]"}
  ```

  Non corrisponde nemmeno al seguente corpo del messaggio:

  ```
  {
      "store": "fans"
      "customer_interests": ["baseball", "basketball"]
  }
  ```

  Tuttavia, corrisponde a qualsiasi elenco di attributi di messaggi *senza* la chiave attributo `store`, ad esempio:

  ```
  "customer_interests": {"Type": "String.Array", "Value": "[\"baseball\", \"basketball\"]"}
  ```

  Corrisponde anche al seguente corpo del messaggio:

  ```
  {
      "customer_interests": ["baseball", "basketball"]
  }
  ```

# Corrispondenza dei valori numerici
<a name="numeric-value-matching"></a>

Filtra i messaggi abbinando i valori numerici ai valori degli attributi del messaggio o ai valori delle proprietà del corpo del messaggio. Nella policy JSON, i valori numerici non sono racchiusi tra virgolette doppie. È possibile disporre delle seguenti operazioni numeriche per il filtro.

**Nota**  
I prefissi sono supportati solo per la corrispondenza di *stringa*.

## Corrispondenza esatta
<a name="numeric-exact-matching"></a>

Quando un valore di proprietà della policy include la parola chiave `numeric` e l'operatore `=`, corrisponde a qualsiasi attributo di messaggio o proprietà del corpo del messaggio con lo stesso nome e lo stesso valore numerico.

Esaminiamo la seguente proprietà della policy:

```
"price_usd": [{"numeric": ["=",301.5]}]
```

Corrisponde a uno dei seguenti attributi di messaggio:

```
"price_usd": {"Type": "Number", "Value": 301.5}
```

```
"price_usd": {"Type": "Number", "Value": 3.015e2}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
   "price_usd": 301.5
}
```

```
{
   "price_usd": 3.015e2
}
```

## Corrispondenza anything-but
<a name="numeric-anything-but-matching"></a>

Quando un valore della proprietà della policy include la parola chiave `anything-but`, corrisponde a qualsiasi attributo del messaggio o valore del corpo del messaggio che *non* include nessuno dei valori delle proprietà della policy.

Esaminiamo la seguente proprietà della policy:

```
"price": [{"anything-but": [100, 500]}]
```

Corrisponde a uno dei seguenti attributi di messaggio:

```
"price": {"Type": "Number", "Value": 101}
```

```
"price": {"Type": "Number", "Value": 100.1}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
   "price": 101
}
```

```
{
   "price": 100.1
}
```

Inoltre, corrisponde anche al seguente attributo di messaggio (poiché contiene un valore che *non è* `100` o `500`):

```
"price": {"Type": "Number.Array", "Value": "[100, 50]"}
```

E corrisponde anche al seguente corpo del messaggio (poiché contiene un valore che *non è* `100` né `500`):

```
{
   "price": [100, 50]
}
```

Tuttavia, non corrisponde al seguente attributo di messaggio:

```
"price": {"Type": "Number", "Value": 100}
```

Né corrisponde al seguente corpo del messaggio:

```
{
   "price": 100
}
```

## Corrispondenza dell'intervallo dei valori
<a name="numeric-value-range-matching"></a>

Oltre all'operatore `=`, una proprietà di policy numerica può includere i seguenti operatori: `<`, `<=`, `>` e `>=`.

Esaminiamo la seguente proprietà della policy:

```
"price_usd": [{"numeric": ["<", 0]}]
```

Corrisponde a qualsiasi attributo di messaggio o proprietà del corpo del messaggio che abbia valori numerici negativi.

Esaminiamo un altro attributo di messaggio:

```
"price_usd": [{"numeric": [">", 0, "<=", 150]}]
```

Corrisponde a qualsiasi attributo di messaggio o proprietà del corpo del messaggio che abbia numeri positivi fino a 150.

# Corrispondenza dei valori di stringa
<a name="string-value-matching"></a>

Filtra i messaggi abbinando i valori delle stringhe ai valori degli attributi del messaggio o ai valori delle proprietà del corpo del messaggio. Nella policy JSON, i valori di stringa sono racchiusi tra virgolette doppie. È possibile utilizzare le seguenti operazioni sulle stringhe per abbinare gli attributi o le proprietà del corpo del messaggio:

## Corrispondenza esatta
<a name="string-exact-matching"></a>

La corrispondenza esatta si verifica quando un valore di proprietà della policy corrisponde a uno o più valori di attributo del messaggio. Per gli attributi `String.Array` di tipo, ogni elemento dell'array viene trattato come una stringa separata per scopi di corrispondenza.

Esaminiamo la seguente proprietà della policy:

```
"customer_interests": ["rugby", "tennis"]
```

Corrisponde ai seguenti attributi di messaggio:

```
"customer_interests": {"Type": "String", "Value": "rugby"}
```

```
"customer_interests": {"Type": "String", "Value": "tennis"}
```

```
"customer_interests": {"Type": "String.Array", "Value": "[\"rugby\", \"tennis\"]"}
```

Corrisponde anche ai seguenti corpi dei messaggi:

```
{
   "customer_interests": "rugby"
}
```

```
{
   "customer_interests": "tennis"
}
```

Tuttavia, non corrisponde ai seguenti attributi del messaggio:

```
"customer_interests": {"Type": "String", "Value": "baseball"}
```

```
"customer_interests": {"Type": "String.Array", "Value": "[\"baseball\"]"}
```

Né corrisponde al seguente corpo del messaggio:

```
{
   "customer_interests": "baseball"
}
```

## Corrispondenza anything-but
<a name="string-anything-but-matching"></a>

Quando un valore della proprietà della policy include la parola chiave `anything-but`, corrisponde a qualsiasi attributo del messaggio o valore del corpo del messaggio che *non* include nessuno dei valori delle proprietà della policy. `anything-but` può essere combinato con `"exists": false`. Per gli attributi `String.Array` di tipo, corrisponde se nessuno degli elementi dell'array è elencato nella proprietà policy.

Esaminiamo la seguente proprietà della policy:

```
"customer_interests": [{"anything-but": ["rugby", "tennis"]}]
```

Corrisponde a uno dei seguenti attributi del messaggio:

```
"customer_interests": {"Type": "String", "Value": "baseball"}
```

```
"customer_interests": {"Type": "String", "Value": "football"}
```

```
"customer_interests": {"Type": "String.Array", "Value": "[\"rugby\", \"baseball\"]"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
   "customer_interests": "baseball"
}
```

```
{
   "customer_interests": "football"
}
```

Inoltre, corrisponde anche al seguente attributo di messaggio (poiché contiene un valore che *non è* `rugby` o `tennis`):

```
"customer_interests": {"Type": "String.Array", "Value": "[\"rugby\", \"baseball\"]"}
```

E corrisponde anche al seguente corpo del messaggio (poiché contiene un valore che non è `rugby` né `tennis`):

```
{
   "customer_interests": ["rugby", "baseball"]
}
```

Tuttavia, non corrisponde ai seguenti attributi del messaggio:

```
"customer_interests": {"Type": "String", "Value": "rugby"}
```

```
"customer_interests": {"Type": "String.Array", "Value": "[\"rugby\"]"}
```

Né corrisponde al seguente corpo del messaggio:

```
{
   "customer_interests": ["rugby"]
}
```

**Utilizzo di un prefisso con `anything-but`**

Per la corrispondenza di stringa, puoi anche utilizzare un prefisso con operatore `anything-but`. Ad esempio, la proprietà della policy seguente nega il prefisso `order-`:

```
"event":[{"anything-but": {"prefix": "order-"}}]
```

Corrisponde a uno dei seguenti attributi:

```
"event": {"Type": "String", "Value": "data-entry"}
```

```
"event": {"Type": "String", "Value": "order_number"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
   "event": "data-entry"
}
```

```
{
   "event": "order_number"
}
```

Tuttavia, non corrisponde al seguente attributo di messaggio:

```
"event": {"Type": "String", "Value": "order-cancelled"}
```

Né corrisponde al seguente corpo del messaggio:

```
{
   "event": "order-cancelled"
}
```

**tutt'altro che jolly**

La seguente proprietà della policy nega il carattere jolly: `*ball`

```
"customer_interests" : [{ "anything-but": { "wildcard": "*ball" }}]
```

Corrisponde ai seguenti attributi:

```
{"customer_interests": ["hockey", "rugby", "soccer] }
```

Tuttavia, non corrisponde al seguente attributo del messaggio:

```
{"customer_interests": ["baseball", "basketball"] }
```

**tutto tranne il suffisso** 

La seguente proprietà politica nega il `-ball`

 suffisso:

```
"customer_interests": [ { "anything-but": { "suffix": "ball" } } ]
```

Corrisponde ai seguenti attributi:

```
{"customer_interests": ["hockey", "rugby", "soccer] }
```

Tuttavia, non corrisponde al seguente attributo del messaggio:

```
 {"customer_interests": ["baseball", "basketball"] }
```

## Equals-ignore-case abbinamento
<a name="string-equals-ignore"></a>

Quando una proprietà della policy include la parola chiave `equals-ignore-case`, verrà effettuata una corrispondenza che ignora le maiuscole/minuscole in qualsiasi valore di attributo dei messaggi o di proprietà del corpo.

Esaminiamo la seguente proprietà della policy:

```
"customer_interests": [{"equals-ignore-case": "tennis"}]
```

Corrisponde a uno dei seguenti attributi di messaggio:

```
"customer_interests": {"Type": "String", "Value": "TENNIS"}
```

```
"customer_interests": {"Type": "String", "Value": "Tennis"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
    "customer_interests": "TENNIS"
}
```

```
{
    "customer_interests": "teNnis"
{
```

## Corrispondenza in base all'indirizzo IP
<a name="string-address-matching"></a>

Puoi utilizzare l'operatore `cidr` per verificare se un messaggio in arrivo proviene da un indirizzo IP o da una subnet specifica. 

Esaminiamo la seguente proprietà della policy:

```
"source_ip":[{"cidr": "10.0.0.0/24"}]
```

Corrisponde a uno dei seguenti attributi di messaggio:

```
"source_ip": {"Type": "String", "Value": "10.0.0.0"}
```

```
"source_ip": {"Type": "String", "Value": "10.0.0.255"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
   "source_ip": "10.0.0.0"
}
```

```
{
   "source_ip": "10.0.0.255"
}
```

Tuttavia, non corrisponde al seguente attributo di messaggio:

```
"source_ip": {"Type": "String", "Value": "10.1.1.0"}
```

Né corrisponde al seguente corpo del messaggio:

```
{
   "source_ip": "10.1.1.0"
}
```

## Corrispondenza in base al prefisso
<a name="string-prefix-matching"></a>

Quando una proprietà della policy include la parola chiave `prefix`, corrisponde a qualsiasi valore di proprietà del messaggio che inizi con i caratteri specificati.

Esaminiamo la seguente proprietà della policy:

```
"customer_interests": [{"prefix": "bas"}]
```

Corrisponde a uno dei seguenti attributi di messaggio:

```
"customer_interests": {"Type": "String", "Value": "baseball"}
```

```
"customer_interests": {"Type": "String", "Value": "basketball"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
   "customer_interests": "baseball"
}
```

```
{
   "customer_interests": "basketball"
}
```

Tuttavia, non corrisponde al seguente attributo di messaggio:

```
"customer_interests": {"Type": "String", "Value": "rugby"}
```

Né corrisponde al seguente corpo del messaggio:

```
{
   "customer_interests": "rugby"
}
```

## Corrispondenza dei suffissi
<a name="string-suffix-matching"></a>

Quando una proprietà della policy include la parola chiave `suffix`, mette in corrispondenza qualsiasi valore di attributo dei messaggio o di proprietà del corpo che inizi con i caratteri specificati.

Esaminiamo la seguente proprietà della policy:

```
"customer_interests": [{"suffix": "ball"}]
```

Corrisponde a uno dei seguenti attributi di messaggio:

```
"customer_interests": {"Type": "String", "Value": "baseball"}
```

```
"customer_interests": {"Type": "String", "Value": "basketball"}
```

Corrisponde anche a uno dei seguenti corpi dei messaggi:

```
{
    "customer_interests": "baseball"
}
```

```
{
    "customer_interests": "basketball"
}
```

Tuttavia, non corrisponde al seguente attributo di messaggio:

```
"customer_interests": {"Type": "String", "Value": "rugby"}
```

Né corrisponde al seguente corpo del messaggio:

```
{
    "customer_interests": "rugby"
}
```

## Carattere jolly
<a name="string-value-wildcard"></a>

 È possibile utilizzare il carattere jolly (\$1) per la corrispondenza con valori di stringa in modelli di eventi. 

La seguente politica utilizza il carattere jolly (\$1):

```
"customer_interests": [ { "wildcard": "*ball" } ]
```

Corrisponde ai seguenti attributi:

```
{"customer_interests": ["baseball", "basketball"] }
```