Estender Universal Resource Scheduling con restricións de recurso personalizadas
Universal Resource Scheduling, o motor de programación subxacente de Dynamics 365 Field Service e Project Service Automation, envíase con amplas capacidades de coincidencia de recursos para reservar os recursos apropiados para un traballo. Mentres que a solución Universal Resource Scheduling se envía con Field Service e Project Service, Universal Resource Scheduling pódese empregar tamén para programar calquera secuencia de traballo en Dynamics 365. Neste artigo veremos como se implementan as restricións de recursos incorporados e como personalizar Universal Resource Scheduling coas restricións de recursos personalizados.
Recursos, requisitos e restricións
Recursos
O núcleo de Universal Resource Scheduling é a entidade do recurso (bookableresource). Cando se crean rexistros de reserva (bookableresourcebooking), están asociados cun rexistro de recurso. Para garantir que se selecciona o recurso correcto, Universal Resource Scheduling envíase con varios filtros e restricións incorporados polos que categorizar os recursos. Exemplos: Tipo de Recurso, que indica se o recurso é un Usuario, Contacto, Conta, Equipamento, etc.; Característica, para filtrar os recursos por habilidades que coñecen; Zona de vendas, para atribuír recursos ao rexións específicas; Unidade organizativa, para basear unha xerarquía de organización, etc.
Un rexistro de recurso e as restricións asociadas baséanse en atributos ou relacións con outras entidades. Por exemplo, Nome e Tipo de Recurso son atributos de entidade de recurso. As características de recursos e as zonas de vendas de recursos son relacións secundarias porque un recurso pode estar asociado a máis dunha delas. Estas entidades son relacións secundarias para o Recurso E a entidade de Característica/Zona de vendas. A unidade organizativa é un atributo de busca na entidade de recurso para a entidade de Unidade organizativa.
Requisitos
Outra entidade importante en Universal Resource Scheduling é a entidade de Requisito de recurso (msdyn_resourcerequirement). A entidade de requisitos rexistra un requisito para realizar o traballo. Captura parámetros sobre o traballo demandado, como os campos de data Desde e Até, restrinxindo o período de tempo en que o traballo se pode realizar; o campo Duración para indicar o canto tempo se prevé que demore o traballo; a Localización do traballom que informa sobre a localización do traballo requirido. A entidade de Requisito tamén captura as restricións do recurso para restrinxir os recursos que se poden realizar e reservarse para este requisito. Como a entidade de Recurso, as restricións do recurso son expresadas como atributos na entidade de requisito ou como relacións con outras entidades. Zona de vendas é un atributo de busca da a entidade de Requisito á entidade de zona de Vendas que indica a zona de vendas na que se realiza o traballo e, por tanto, debemos a atopar un recurso da mesma zona de vendas. A característica de requisito é unha relación secundaria que relaciona o Requisito coa entidade de característica que expresa os coñecementos necesarios para finalizar o traballo e, por tanto, o requisito só pode coincidir con recursos con coñecementos similares.
Restricións enviadas en Universal Resource Scheduling
A seguinte é unha lista de restricións que se envían con Universal Resource Scheduling:
- Características - Poden usarse para basear as habilidades que ten un recurso. Tamén admite valores de clasificación opcionais para valorar os coñecementos do recurso en cada habilidade
- Categorías - os recursos poden asociarse a categorías
- Zonas de vendas - para atribuír os recursos a rexións da zona de vendas
- Unidades organizativas - para basear unha xerarquía de organización
- Tipo de recurso - Define o tipo de recurso
- Equipos - os equipos dos que é membro un recurso
- Unidades empresariais - de que unidade empresarial forma parte o recurso
Filtraxe no panel de programación
O panel de programación mostra unha lista de recursos e os recursos atribuídos a eles. O panel de Filtro no panel de programación permítelle filtrar a lista de recursos en función das súas restricións; por exemplo, seleccionar un tipo de recurso de usuario na lista despregable de Tipos de Recursos filtrará a lista de recursos para os que son do tipo Usuario. De forma similar, pode filtrar recursos por características ou zonas de vendas coincidentes.
Utilizar o panel de Filtro para filtrar recursos é un método para localizar recursos coincidentes. Este método utilízase cando desexa mostrar manualmente unha lista de recursos correspondentes a un conxunto específico de restricións.
Localizar recursos dispoñibles co asistente de Programación
Na parte inferior do panel de Programación atopará unha lista de rexistros de Requisitos. Pode seleccionar un deles e escoller para atopar dispoñibilidade. Esta acción abre o Asistente de programación. O asistente de programación utiliza as restricións que se capturaron no rexistro seleccionado de Requisito para encontrar os recursos correspondentes que están dispoñibles para seren reservados. Só se mostran no panel os recuros que coinciden coas restricións no Requisito e que están dispoñibles no período de tempo solicitado especificado no Requisito .
Unha experiencia similar está dispoñible mediante un botón de fita "Reservar" dispoñible na entidade Requisito e outras entidades programables en formualrios ou visualizacións de listas de Dynamics 365. Ao premer "Reservar", ábrese o asistente de programación mostrando recursos que coinciden coas restricións do rexistro seleccionado de Requisito.
A diferenza do modo previamente mencionado no panel de Programación, onde se utiliza o panel de Filtro para filtrar recursos manualmente, en modo de Asistente de Programación, o panel de Filtro enche automaticamente ás restricións do recurso desde o rexistro de Requisito e só se mostran os recursos que coinciden.
Como funciona a coincidencia de restricións
Entidades de restricións
Algunhas restricións están especificadas como atributos directamente na entidade Recurso mentres que outras están definidas a través de relacións. As relacións son necesarias cando unha restrición fai referencia a unha segunda entidade principal.
Consideremos unrexistro de Recurso e a zona de Vendas asociada e as restricións de características.
Primeiro, os rexistros principais. Temos zonas de vendas almacenadas na entidade zona de Vendas:
| Zona de vendas |
|---|
| Ourense |
| Vigo |
| Pontevedra |
Tamén temos características na entidade Característica:
| Característica |
|---|
| Xestor de proxectos |
| Deseñador |
| Analista financeiro |
Entidade de unidade organizativa
| Unidade organizativa |
|---|
| Contoso EUA |
| Contoso UE |
Finalmente, temos a entidade Recurso:
| Recurso | Tipo de recurso | Unidade organizativa |
|---|---|---|
| Antón Carballo | User | Contoso EUA |
| Uxío Lariño | Contacto | Contoso UE |
Mentres un rexistro de Recurso individual traballa para capturar restricións cun único valor, como o Tipo de Recurso e a Unidade organizativa anteriormente indicada. Se queremos asociar un Recurso a varios rexistros de zona de Vendas ou característica, debemos usar unha terceira entidade, unha relación de varios a varios (N:N) para almacenar estas asociacións.
Utilizamos a entidade de zona de Vendas do Recurso para asociar varias zonas de vendas a un recurso.
Rexistros de zona de vendas:
| Recurso | Zona de vendas |
|---|---|
| Antón Carballo | Ourense |
| Antón Carballo | Vigo |
| Uxío Lariño | Pontevedra |
e a entidade Característica do Recurso para almacenar varias características para un recurso.
Rexistros da característica do recurso:
| Recurso | Característica |
|---|---|
| Antón Carballo | Deseñador |
| Uxío Lariño | Xestor de proxectos |
| Uxío Lariño | Analista financeiro |
De forma semellante á Recurso, un rexistro de Requisitos captura valued soa restricións e os rexistros secundarios almacenar varias valued restricións.
Esta é a entidade Requisito:
| Requisito | Duración | Zona de vendas |
|---|---|---|
| Tarefa 1 | 1 h | Ourense |
| Tarefa 2 | 1 h | Pontevedra |
A entidade Característica do requisito:
Rexistros da característica do requisito:
| Requisito | Característica |
|---|---|
| Tarefa 1 | Deseñador |
| Tarefa 2 | Xestor de proxectos |
| Tarefa 2 | Analista financeiro |
A veces, os requisitos poden ter unha restrición modelada como un atributo de busca, mentres que o recurso pode almacenar os atributos coincidentes na táboa de N:N. Por exemplo, para o Requisito, a restrición de zona de vendas é un atributo de busca para a entidade de zona de Vendas. Un Requisito captura unha demanda de traballo e a zona de vendas en que se realizará o traballo. Un rexistro de Recurso, no entanto, pode asociarse a varios rexistros de zona de Vendas.
Bolsas de propiedades de restricións
Cando o usuario selecciona valores no panel de Filtro e seleccione o botón de Busca, os valores envíanse á API que coincide co Recurso. No caso de restricións con varios valores, o panel de Filtro mostra os datos desde as entidades principais Zona de Vendas e Característica e inclúe os valores seleccionados na bolsa de propiedade das restricións.
Este é un exemplo da bolsa de propiedade con restricións envíada á API que coincide co Recurso:
| Nome | Value |
|---|---|
ResourceType |
User |
Territories |
Ourense Vigo |
Isto indícalle á API que coincide co Recurso que atope recursos do tipo de Usuario que estean asociados coas zonas de vendas de Ourense ou Vigo.
Cando está no Asistente de Programación, as restricións recupéranse dun rexistro de Requisito mediante a API de Restricións de Requisitos. As restricións recuperads énchense previamente no panel de Filtro e envíanse á API que coincide co Recurso.
A API de Recuperar Restricións de requisitos consulta o rexistro de Requisito e todas as restricións secundarios relacionadas (por exemplo, a característica de Requisito). Responde cunha bolsa de propiedade de restricións que expresa todas as restricións do recurso capturadas no Requisito seleccionado.
Este é unha resposta de exemplo da API de Recuperar Restricións de requisitos:
| Nome | Value |
|---|---|
Requirement |
Tarefa 2 |
Duration |
1 h |
Territories |
Pontevedra |
Characteristics |
Xestor de proxectos Analista financeiro |
A API que coincide co Recurso recibe como entrada a bolsa de propiedade de restricións e consultas para recursos coincidentes. Os recursos coincidentes móstranse no panel de Programación ou no Asistente de Programación.
Resumo das entidades utilizadas para a coincidencia de recursos
- Entidades principais de exemplo
- Zona de Vendas - Referenciada como unha restrición
- Característica - Referenciada como unha restrición
- Recurso - Asignado a reservas
- Zona de Vendas do recurso - Asocia Recursos a zonas de Vendas
- Característica do recurso - Asocia Recursos a Características
- Entidades de transaccións de exemplo
- Requisito - Captura unha demanda de traballo e referencia unha zona de Vendas
- Característica do requisito - Asocia requisitos a Características
Resumo dos fluxos que coinciden cos recursoss
Filtraxe manual. Panel de filtro > API que coincide co Recurso
- Un usuario engade manualmente restricións no panel de Filtro
- As restricións envíanse á API que coincide co Recurso
- Móstrase a lista filtrada de recursos
Filtraxe de requisitos. API de Recuperar Restricións dos requisitos > Panel de filtro > API que coincide co Recurso
- Un usuario atopa dispoñibilidade para un rexistro de Requisito (desde o panel de Programación ou desde o botón Reservar na fita).
- As restricións recupéranse mediante a API de Recuperar Restricións do requisito e móstranse no panel de Filtro.
- As restricións envíanse á API que coincide co Recurso
- Móstrase a lista filtrada de recursos
Extensión de Universal Resource Scheduling con restricións personalizadas
Universal Resource Scheduling pode estenderse con restricións do recurso personalizadas. A extensión de restricións funciona da mesma maneira que as que están compiladas en Universal Resource Scheduling, modélanse como atributos e relacións en Dynamics 365.
Unha guía paso a paso con exemplos de código necesarios para cada paso descríbese en Extensión de Universal Resource Scheduling: Atopar recursos por idioma - guía paso a paso
Restricións personalizadas
Utilizaremos "idioma" como un escenario de exemplo. Unha organización quere filtrar recursos en función do idioma que falan. Tamén queren capturar no rexistro Requisito o idioma necesario para unha tarefa. Esta restrición segue un padrón semellante á restrición de zona de Vendas incorporada. Unha nova entidade principal de Idioma almacena os idiomas diferentes que pode falar un recurso. Un rexistro de Recurso pode asociarse a varios Idiomas mediante unha entidade de relación de varios a varios. Na entidade Requisito, crearemos dous atributos de busca novos: Required Language e Secondary Language. Ao buscar recursos dispoñibles para un requisito, só se mostrarán os recursos asociados ao Required Language ou ao Secondary Language.
Posto que as restricións extensibles funcionan completamente co modelo relacional de Dynamics 365, calquera estrutura utilizada para expresar restricións pode utilizarse en Universal Resource Scheduling. Este é un exemplo máis eficaz de restricións personalizadas. Supoñamos que unha organización recolle produtos desde unha localización e entregaos a unha localización do cliente. A entidade do Recurso está estendida cun atributo de Maximum Weight describindo o máximo peso que pode llevar, en caso dun recurso vehículo. A entidade Requisito está relacionada coa entidade de produto de Dynamics 365 cunha relación de varios a varios; cada Produto tamén obtén un novo atributo de Weight. Cando se crea un rexistro de Requisito para capturar o traballo requirido, está relacionado con todos os produtos necesarios para finalizar o traballo. Cando un usuario localiza dispoñibilidade para un Requisito, recupérase o peso total de todos os rexistros de Produto relacionados e só se devolven os recursos que poden levar este peso, definidos no atributo Maximum Weight.
Aquí describiremos a restrición de idioma personalizada. En primeiro lugar, temos a nova entidade de Idioma:
| Language |
|---|
| Inglés |
| Español |
e a nova entidade secundaria de varios a varios do idioma do Recurso:
| Recurso | Language |
|---|---|
| Antón Carballo | Inglés |
| Uxío Lariño | Inglés |
| Uxío Lariño | Español |
Este é o entidade de Requisito cos nosos dous novos atributos, Idioma requerido e Idioma Secundario, que representan os idiomas que o recurso precisa falar para coincidir con este requisito:
| Requisito | Duración | Zona de vendas | Idioma requirido | Idioma secundario |
|---|---|---|---|---|
| Tarefa 1 | 1 h | Ourense | Inglés | --- |
| Tarefa 2 | 1 h | Pontevedra | Español | Inglés |
Puntos de extensibilidade
Segundo os fluxos que coinciden con recursos descritos enriba, estes son os dous puntos extensibilidade que precisamos modificar para que funcionen as restricións personalizadas:
API de Recuperar restricións dos requisitos
A API ten que ler os nosos novos atributos Idioma requirido e Idioma Secundario de forma que cando un usuario localiza dispoñibilidade para un Requisito, recupéranse as novas restricións.
Panel de filtros
Un usuario debe poder seleccionar a partir dunha lista de rexistros de Idioma no panel de Filtro para filtrar unha coincidencia de recursos. Cando se busca dispoñibilidade para un Requisito, o panel de Filtro debería mostrar o Idioma Requirido e o Idioma Secundario desde o rexistro do Requisito predefinido seleccionado previamente na lista de Idiomas.
API de Coincidencia de recursos
A API obterá como entrada as novas restricións de Idioma; só ten que devolver recursos que falen os idiomas seleccionados.
Consultas extensibles
Internamente, a API de Recuperar Restricións dos requisitos (#1 enriba) e a API de Recursos coincidentes (#3 enriba) utilizan FetchXML para consultar datos de Dynamics 365. A API de Recuperar Restricións de requisitos emite varias consultas para recuperar o rexistro de Requisito e as restricións secundarias (por exemplo, característica do requisito, etc.) A API de Recursos coincidentes, segundo ás restricións do recurso pasadas como entrada, crearán dinamicamente a consulta de FetchXML correcta, de forma que só os rexistros de Recurso coincidentes cos criterios de FetchXML especificados se devolverán desde Dynamics 365.
Na actualización de xullo de 2017 de Universal Resource Scheduling, introduciuse Universal FetchXML (UFX) para admitir a coincidencia de recursos extensibles. Dúas importantes funcionalidades que UFX engade a FetchXML son: 1) Varios conxuntos de resultados, unha única Consulta UFX pode devolver resultados de varias entidades e 2) FetchXML Dinámica, unha Consulta de UFX pode crear dinamicamente FetchXML baseándose en datos de entrada.
Con UFX, unha consulta única pode ser creada para consulta para un rexistro de Requisito e todos os rexistros secundarios. A API de Recuperar Restricións de requisitos executa unha Consulta de UFX personalizable para recuperar un Requisito e as restricións secundarias. A consulta pódese personalizar para recuperar tamén rexistros de restrición personalizados.
A bolsa de propiedades de restricións devolta desde a API de Recuperar Restricións de requisitos pásase como entrada á API de Recursos coincidentes. A API executa unha consulta de UFX personalizable. Con UFX, a consulta utiliza as restricións de entrada para crear dinamicamente a FetchXML correcta para localizar os recursos correspondentes. Esta consulta UFX, tamén pode modificarse para crear o FetchXML correcto que devolva só recursos correspondentes coas restricións personalizadas.
Deseño de filtro extensible e Modelo de Recursos
Na actualización de Xullo de 2017 de Universal Resource Scheduling, o panel de Filtro (#2 enriba) actualizouse para admitir a personalización a través dunha definición de deseño de XML. O novo deseño admite controis despregables para mostrar unha lista de rexistros de entidades principais e os habituais controis de number, datetime e checkbox. Pódese modificar o deseño para permitir aos usuarios seleccionar rexistros de entidades personalizadas externas. As restricións personalizadas, como as que se envían con Universal Resource Scheduling, pásanse como entrada á API de coincidencia de Recursos.
Outro punto de extensibilidade lateral do cliente dispoñible na actualización de Xullo de 2017 é cela de recursos. A cela de recursos represéntase a través dun modelo de Handlebars.js personalizable. Os resultados da API Coincidente de Recursos están dispoñible para o modelo. Por tanto, personalizando a consulta que executou a API Coincidente de Recursos, os datos personalizados poden representarse na cela de recursos.
Unha guía paso a paso con exemplos de código necesarios para cada paso descríbese en Extensión de Universal Resource Scheduling: Atopar recursos por idioma - guía paso a paso
Notas adicionais
- O deseño do filtro non se pode configurar actualmente cando unha entidade programable usa un grupo de requirimentos asociado no canto dun requirimento de recursos.
Consulte tamén
Notas da versión de extensibilidade de Universal Resource Scheduling
Hinweis
Pode indicarnos as súas preferencias para o idioma da documentación? Realice unha enquisa breve. (teña en conta que esa enquisa está en inglés)
Esta enquisa durará sete minutos aproximadamente. Non se recompilarán datos persoais (declaración de privacidade).
Comentarios
Proximamente: Ao longo de 2024, retiraremos gradualmente GitHub Issues como mecanismo de comentarios sobre o contido e substituirémolo por un novo sistema de comentarios. Para obter máis información, consulte: https://aka.ms/ContentUserFeedback.
Enviar e ver os comentarios