翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AND/OR ロジック
フィルターポリシーで AND/OR ロジックを使用し、Amazon SNS でメッセージ属性または本文プロパティを照合する方法について説明します。これにより、より正確で柔軟なメッセージフィルタリングが可能になります。
## AND ロジック
複数のプロパティ名を使用して AND ロジックを適用できます。
次のポリシーについて考えます。
```
{
"customer_interests": ["rugby"],
"price_usd": [{"numeric": [">", 100]}]
}
```
このポリシーは、`customer_interests` の値が `rugby` に設定され、*さらに* `price_usd` の値が 100 を超える値に設定されているメッセージ属性またはメッセージ本文プロパティと一致します。
**注記**
AND ロジックを同じ属性の値に適用することはできません。
## OR ロジック
プロパティ名に複数の値を割り当てることで OR ロジックを適用できます。
次のポリシーについて考えます。
```
{
"customer_interests": ["rugby", "football", "baseball"]
}
```
このポリシー属性は、`customer_interests` の値が `rugby`、`football`、*または* `baseball` に設定されているメッセージ属性またはメッセージ本文プロパティと一致します。
## OR 演算子
`"$or"` 演算子を使用してフィルターポリシーを明示的に定義し、ポリシー内の複数の属性間の OR 関係を表すことができます。
Amazon SNS は、ポリシーが以下の条件をすべて満たしている場合にのみ `"$or"` 関係を認識します。これらの条件がすべて満たされない場合、`"$or"` はポリシー内の他の文字列と同様に通常の属性名として扱われます。
+ ルールには `"$or"` フィールド属性が付けられ、その後に配列 (`“$or” : []` など) が続きます。
+ `"$or"` 配列には少なくとも次の 2 つのオブジェクトがあります: `"$or": [{}, {}]`。
+ `"$or"` 配列内のどのオブジェクトにも、予約キーワードであるフィールド名はありません。
それ以外の場合は、ポリシー内の他の文字列と同様に、`"$or"` は通常の属性名として扱われます。
数値とプレフィックスは予約キーワードであるため、以下のポリシーは OR 関係として解析されません。
```
{
"$or": [ {"numeric" : 123}, {"prefix": "abc"} ]
}
```
**`OR` 演算子の例**
標準の `OR`:
```
{
"source": [ "aws.cloudwatch" ],
"$or": [
{ "metricName": [ "CPUUtilization" ] },
{ "namespace": [ "AWS/EC2" ] }
]
}
```
このポリシーのフィルターロジックは次のとおりです。
```
"source" && ("metricName" || "namespace")
```
このポリシー属性は、以下のメッセージ属性セットのいずれとも一致します。
```
"source": {"Type": "String", "Value": "aws.cloudwatch"},
"metricName": {"Type": "String", "Value": "CPUUtilization"}
```
または
```
"source": {"Type": "String", "Value": "aws.cloudwatch"},
"namespace": {"Type": "String", "Value": "AWS/EC2"}
```
以下のメッセージ本文のいずれとも一致します。
```
{
"source": "aws.cloudwatch",
"metricName": "CPUUtilization"
}
```
または
```
{
"source": "aws.cloudwatch",
"namespace": "AWS/EC2"
}
```
### `OR` 関係を含むポリシー制約
次のポリシーについて考えます。
```
{
"source": [ "aws.cloudwatch" ],
"$or": [
{ "metricName": [ "CPUUtilization", "ReadLatency" ] },
{
"metricType": [ "MetricType" ] ,
"$or" : [
{ "metricId": [ 1234, 4321 ] },
{ "spaceId": [ 1000, 2000, 3000 ] }
]
}
]
}
```
このポリシーのロジックは次のように簡略化することもできます。
```
("source" AND "metricName")
OR
("source" AND "metricType" AND "metricId")
OR
("source" AND "metricType" AND "spaceId")
```
OR 関係のあるポリシーの複雑さの計算は、各 OR ステートメントの組み合わせの複雑さの合計として簡略化できます。
組み合わせの合計は次のように計算されます。
```
(source * metricName) + (source * metricType * metricId) + (source * metricType * spaceId)
= (1 * 2) + (1 * 1 * 2) + (1 * 1 * 3)
= 7
```
`source` には 1 つの値、`metricName` には 2 つの値、`metricType` には 1 つの値、`metricId` には 2 つの値、`spaceId` には 3 つの値があります。
次のネストされたフィルターポリシーについて考えてみます。
```
{
"$or": [
{ "metricName": [ "CPUUtilization", "ReadLatency" ] },
{ "namespace": [ "AWS/EC2", "AWS/ES" ] }
],
"detail" : {
"scope" : [ "Service" ],
"$or": [
{ "source": [ "aws.cloudwatch" ] },
{ "type": [ "CloudWatch Alarm State Change"] }
]
}
}
```
このポリシーのロジックは次のように簡略化できます。
```
("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")
```
組み合わせの合計の計算は、キーのネストレベルを考慮する必要がある点を除いて、ネストされていないポリシーでも同じです。
組み合わせの合計は次のように計算されます。
```
(2 * 2 * 2) + (2 * 2 * 2) + (2 * 2 * 2) + (2 * 2 * 2) = 32
```
`metricName` には 2 つの値、`namespace` には 2 つの値があります。`scope` は、1 つの値を持つ 2 レベルのネストされたキー、`source` は 1 つの値を持つ 2 レベルのネストされたキー、`type` は 1 つの値を持つ 2 レベルのネストされたキーです。