As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Noções básicas sobre as regras de sinalizador de atributos multivariante
<a name="appconfig-creating-multi-variant-feature-flags-rules"></a>

Ao criar uma variante de sinalizador de atributos, especifique uma regra para ela. Regras são expressões que usam valores de contexto como entrada e produzem um resultado booliano como saída. Por exemplo, é possível definir uma regra para selecionar uma variante de sinalizador para usuários beta, identificada pelo ID da conta, testando uma atualização da interface de usuário. No caso desse cenário, faça o seguinte:

1. Crie um perfil de configuração de sinalizador de atributos chamado *Atualização da interface de usuário.*

1. Crie um sinalizador de atributos chamado *ui\_refresh*.

1. Depois de criá-lo, edite-o para adicionar variantes.

1. Crie e habilite uma nova variante chamada *BetaUsers*.

1. Defina uma regra para *BetaUsers*que selecione a variante se a ID da conta do contexto da solicitação estiver em uma lista de IDs de conta aprovadas para visualizar a nova experiência beta.

1. Confirme se o status da variante padrão está definido como **Desativado**.

**nota**  
As variantes são avaliadas como uma lista ordenada com base na ordem em que são definidas no console. A variante no início da lista será avaliada primeiro. Se nenhuma regra corresponder ao contexto fornecido, AWS AppConfig retornará a variante Default.

Quando AWS AppConfig processa a solicitação do sinalizador de recurso, ele compara primeiro o contexto fornecido, que inclui o accountId (neste exemplo) com a variante. BetaUsers Se o contexto corresponder à regra de BetaUsers, AWS AppConfig retornará os dados de configuração da experiência beta. Se o contexto não incluir uma ID da conta ou se a ID da conta terminar em algo diferente de 123, AWS AppConfig retornará os dados de configuração da regra padrão, o que significa que o usuário visualiza a experiência atual na produção.

**nota**  
Para obter mais informações sobre como recuperar os sinalizadores de atributos multivariante, consulte [Recuperar sinalizadores de atributos básicos e multivariante](appconfig-integration-retrieving-feature-flags.md).

## Entender o operador split
<a name="appconfig-creating-multi-variant-feature-flags-rules-operators-split"></a>

A seção a seguir descreve como o operador `split` se comporta quando usado em diferentes cenários. Como lembrete, `split` é avaliado como `true` para uma determinada porcentagem de tráfego com base em um hash consistente do valor de contexto fornecido. Para entender melhor, considere o seguinte cenário de linha de base que usa a divisão com duas variantes:

```
A: (split by::$uniqueId pct::20)
C: <no rule>
```

Como esperado, fornecer um conjunto aleatório de valores `uniqueId` produz uma distribuição que é aproximadamente:

```
A: 20%
C: 80%
```

Se você adicionar uma terceira variante, mas usar a mesma porcentagem de divisão da seguinte maneira:

```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::20)
C: <default>
```

A distribuição fica da seguinte forma:

```
A: 20%
B: 0%
C: 80%
```

Essa distribuição possivelmente inesperada acontece porque cada regra de variante é avaliada em ordem, e a primeira correspondência define a variante retornada. Quando a regra A é avaliada, 20% dos valores `uniqueId` correspondem a ela, então a primeira variante é retornada. Em seguida, a regra B é avaliada. No entanto, todos os valores `uniqueId` que corresponderiam à segunda instrução dividida já foram correspondidos pela regra de variante A. Portanto, nenhum valor corresponde a B. Em vez disso, a variante padrão é retornada.

Agora, considere um terceiro exemplo.

```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::25)
C: <default>
```

Como no exemplo anterior, os primeiros 20% dos valores `uniqueId` correspondem à regra A. Para a regra da variante B, 25% de todos os valores `uniqueId` seriam correspondentes. Porém, a maioria deles correspondia à regra A. Isso deixa 5% do total para a variante B, com o restante recebendo a variante C. A distribuição teria a seguinte aparência:

```
A: 20%
B: 5%
C: 75%
```

**Usar a propriedade `seed`**  
Você pode usar a propriedade `seed` para garantir que o tráfego seja dividido de maneira consistente para um determinado valor de contexto, independentemente de onde o operador split seja usado. Se você não especificar `seed`, o hash será *localmente* consistente, o que significa que o tráfego será dividido de forma consistente para esse sinalizador, mas outros sinalizadores que receberem o mesmo valor de contexto poderão dividir o tráfego de maneira diferente. Se `seed` for fornecido, cada valor exclusivo dividirá o tráfego de forma consistente entre sinalizadores de atributos, perfis de configuração e Contas da AWS.

Os clientes costumam usar o mesmo valor `seed` em todas as variantes em um sinalizador ao dividir o tráfego na mesma propriedade de contexto. No entanto, às vezes pode fazer sentido usar um valor de semente diferente. Confira um exemplo que usa sementes diferentes para as regras A e B:

```
A: (split by::$uniqueId pct::20 seed::"seed_one")
B: (split by::$uniqueId pct::25 seed::"seed_two")
C: <default>
```

Como antes, 20% dos valores `uniqueId` equivalentes correspondem à regra A. Isso significa que 80% dos valores são aprovados e testados em relação à regra da variante B. Como a semente é diferente, não há correlação entre os valores que correspondem a A e os que correspondem a B. No entanto, existem somente 80% dos valores `uniqueId` a serem divididos com 25% desse número correspondente à regra B, e 75% não. Isso funciona para a seguinte distribuição:

```
A: 20%
B: 20% (25% of what falls through from A, or 25% of 80%) 
C: 60%
```