| Propriedade | Valor |
|---|---|
| ApiUrl | Fields@Entities@Paths |
| DefaultPropertyName | null |
| DisplayPropertyName | null |
| EntityId | 94 |
| Icon | null |
| Importable | false |
| IsLoggedResponse | null |
| Propriedade | Tipo |
|---|---|
| Id | number |
| EntityId | number |
| DestinationEntityId | number |
| Default | boolean |
| Propriedade | Tipo |
|---|---|
| Fields | Array |
O FieldPath pode ser entendido como um mapa, que leva de uma entidade para outra. Imagine que você quer o valor do Estado do CLIENTE de um negócio para calcular uma fórmula ou para utilizar em uma integração, como buscar esse valor?
Você poderia criar uma função ‘getStateFromDealContact’ e de forma manual buscar o Estado do CLIENTE de um Negócio. O problema é, imagine que em um outro momento você queira o Estado do CONTATO do Negócio, quase sempre são o mesmo, mas não necessariamente. Agora você teria que criar uma função como ‘getStateFromDealPerson’. Percebe como no final, você teria que criar uma função para cada relacionamento no ploomes?
O FieldPath serve exatamente para criar caminhos entre as entidades que podem ser seguidos de maneira dinâmica.
Agora que entendemos o motivo por trás dos FieldPath, podemos focar em sua utilização. No caso anterior, queriamos encontrar o Estado de um CLIENTE de um negócio. O FieldPath que nos daria esse caminho é este:
{
"Id": 171,
"EntityId": 2, // Id da entidade Negõcios
"DestinationEntityId": 26, //Id da entidade Estado
"Default": true,
"Fields": [
{
"Id": 271,
"PathId": 171,
"FieldKey": "deal_contact",
"Ordination": 1,
"Field": {
"PropertyName": "Contact",
"UpdatePropertyName": "ContactId"
}
},
{
"Id": 272,
"PathId": 171,
"FieldKey": "contact_state",
"Ordination": 2,
"Field": {
"PropertyName": "State",
"UpdatePropertyName": "StateId"
}
}
]
}
Note que o valor de EntityId é 2, o Id da entidade Negócios, já o DestinationEntityId é 26, o Id da entidade Estado.
Imaginemos então que temos esse negócio:
{
// ... outras propriedades de negócios
"ContactId": 9032161
}
O primeiro passo é iterarmos sobre os Fields do FieldPath, para isso É MUITO IMPORTANTE ORDENARMOS OS FIELDS DE ACORDO COM O A PROPRIEDADE ORDINATION.
O primeiro FieldPathField é
{
"Id": 271,
"PathId": 171,
"FieldKey": "deal_contact",
"Ordination": 1,
"Field": {
"PropertyName": "Contact",
"UpdatePropertyName": "ContactId"
}
}
Vamos então buscar na entidade inicial o valor deste campo, no exemplo o valor seria ContactId:9032161.
Deve-se então buscar, utilizando a api pública o Contato cujo Id é igual a esse valor, chegariamos então nesse objeto
{
"Id": 9032161,
"Name": "John Doe",
"StateId": 21
// ... outras propriedades de contato
}
Com o objeto da próxima entidade, devemos então ir para o próximo campo do nosso FieldPath.
{
"Id": 272,
"PathId": 171,
"FieldKey": "contact_state",
"Ordination": 2,
"Field": {
"PropertyName": "State",
"UpdatePropertyName": "StateId"
}
}
Olhando para o Contato que acabamos de pegar, temos o valor para esse campo de StateId:21
Após buscar na API o valor do Estado com o Id igual a 21, obtendo-se
{
"Id": 21,
"Short": "RS",
"Name": "RIO GRANDE DO SUL",
"CountryId": 76
}
Pronto, esse é o objeto que devemos considerar como valor.
Veja no exemplo, dois FieldPaths conectando Negócios a Contatos
[
{
"Id": 40,
"EntityId": 2,
"DestinationEntityId": 1,
"Default": true,
"Fields": [
{
"Id": 69,
"PathId": 40,
"FieldKey": "deal_contact",
"Ordination": 1,
"Field": {
"PropertyName": "Contact",
"UpdatePropertyName": "ContactId",
"ApiUrl": null
}
}
]
},
{
"Id": 79,
"EntityId": 2,
"DestinationEntityId": 1,
"Default": false,
"Fields": [
{
"Id": 136,
"PathId": 79,
"FieldKey": "deal_person",
"Ordination": 1,
"Field": {
"PropertyName": "Person",
"UpdatePropertyName": "PersonId",
"ApiUrl": null
}
}
]
}
]
Por isso utilize sempre o FieldPathId para ter o caminho exato a percorrer.