clase <SI-Namespace>::skeleton::fields::<Field>

usar

El método RegisterGetHandler se invoca en el lado del servidor sobre el objeto de campo de un skeleton ([SWS_CM_00114]). Solo existe en el código generado si en la descripción de interfaz se ha configurado un getter para el campo en cuestión (Field.hasGetter == TRUE) (EXP ARAComAPI §5.4.8.1 «Registering Getters»). Se pasa un callback handler de tipo std::function<ara::core::Future<FieldType>()>, el cual es invocado por la implementación del binding ante una solicitud Get() entrante de un proxy.

El registro de dicho manejador es completamente opcional (EXP ARAComAPI §5.4.8.1 «Registering Getters»). Por lo general, la implementación del servicio no requiere un manejador de getter, ya que Communication Management almacena en caché el último valor establecido mediante Update() y responde a las solicitudes de proxy de forma autónoma. Un manejador tiene sentido sobre todo si la determinación del valor del campo requiere mucho tiempo o cómputo y, por lo tanto, solo debe realizarse de forma asíncrona mediante el patrón promise/future ante una necesidad real.

Tratamiento de errores y condiciones límite

La función no tiene valor de retorno, está declarada como noexcept y es segura frente a excepciones (exception safe) ([SWS_CM_00114]). Si el invocable suministrado no existe o es null, se produce el error InvalidHandlerViolation ([SWS_CM_00114]).

Interacción

A diferencia de RegisterSetHandler, cuya invocación es obligatoria si hay un setter presente (EXP ARAComAPI §5.4.8.2 «Registering Setters»), RegisterGetHandler sigue siendo puramente opcional. Si el manejador se debe procesar de forma asíncrona en un contexto de ejecución específico, se encuentra disponible adicionalmente la función de plantilla sobrecargada con ExecutorT ([SWS_CM_11360]).

usar

El método RegisterGetHandler en el espacio de nombres <SI-Namespace>::skeleton::fields::<Field> registra una devolución de llamada del lado de la aplicación (handler) que es invocada por la vinculación de comunicación ante una llamada Get() entrante de un proxy ([SWS_CM_11360], EXP ARAComAPI §5.4.8.1 «Registering Getters»). A diferencia de la sobrecarga básica sin parámetros [SWS_CM_00114], el método recibe un contexto de ejecución executor de tipo ExecutorT, en el cual la ejecución del callback se efectúa de forma asíncrona ([SWS_CM_11360]). Como ejecutor se puede emplear el ara::core::Executor estandarizado o un tipo específico de usuario con la misma interfaz ([SWS_CM_11360]).

El manejador registrado devuelve un ara::core::Future<FieldType>, desacoplando así el cálculo del valor del campo mediante el patrón promise/future ([SWS_CM_11360], EXP ARAComAPI §5.4.8.1 «Registering Getters»). El registro es completamente opcional: si no hay ningún manejador registrado, Communication Management responde a las peticiones de forma autónoma con el último valor establecido mediante Update() (EXP ARAComAPI §5.4.8.1 «Registering Getters»). Un manejador getter es adecuado principalmente para determinar bajo demanda valores de campo complejos o que requieren mucho tiempo (EXP ARAComAPI §5.4.8.1 «Registering Getters»).

Restricciones y tratamiento de errores

El método existe en el skeleton exclusivamente si se ha configurado un getter para el campo en el IDL (Field.hasGetter == TRUE, [SWS_CM_00114], EXP ARAComAPI §5.4.8.1 «Registering Getters»). RegisterGetHandler está declarado como noexcept; no obstante, si se proporciona un invocable (callable) no válido o vacío, se produce un InvalidHandlerViolation ([SWS_CM_11360]). Interpretación: el ejecutor proporcionado debería tener que permanecer válido durante todo el tiempo de uso del manejador, ya que las peticiones entrantes se dirigen de forma asíncrona a su contexto. Pregunta Q-c58eb22b06a8c27c (abierta)

usar

El método RegisterSetHandler sirve, en el lado del servidor (skeleton), para registrar una función de callback que se invoca al recibir una solicitud Set() de un cliente para un campo [SWS_CM_00116]. El método existe exclusivamente si el campo ofrecido está configurado con soporte para setter (Field.hasSetter == TRUE) [SWS_CM_00116]. A diferencia del registro del getter, la llamada a RegisterSetHandler es obligatoria, ya que la implementación del servidor debe validar previamente los valores de campo nuevos o actualizados de clientes anónimos EXP ARAComAPI §5.4.8.2 «Registering Setters».

El manejador registrado recibe el nuevo valor como argumento y devuelve un ara::core::Future<FieldType> con el valor efectivo, eventualmente corregido [SWS_CM_00116], EXP ARAComAPI §5.4.8.2 «Registering Setters». Este valor efectivo es aceptado implícitamente por la gestión de comunicación y publicado a los clientes; por lo tanto, una llamada explícita a Update() dentro del manejador es superflua EXP ARAComAPI §5.4.8.2 «Registering Setters».

Tratamiento de errores y condiciones límite

La función está definida como noexcept y es segura frente a excepciones [SWS_CM_00116]. Si se transfiere un callable inexistente o no válido (null), se produce una vulneración de la especificación en forma de InvalidHandlerViolation [SWS_CM_00116]. Interpretación: Es de suponer que el registro debe realizarse antes de ofrecer el servicio mediante OfferService() para poder recibir solicitudes entrantes de clientes desde el principio. Pregunta Q-d45be0a899ddb6dd (abierta)

Interacción

Además del método base, existe una sobrecarga de plantilla [SWS_CM_11362] con la que la ejecución del manejador puede vincularse a un contexto de ejecución específico (ExecutorT según [SWS_CM_11360]) EXP ARAComAPI.

La función de plantilla RegisterSetHandler registra en el nivel de servidor o de skeleton de un campo una función de callback que se invoca tan pronto como un cliente transmite una solicitud Set() ([SWS_CM_11362], [SWS_CM_00116]). La interfaz solo existe si el campo de servicio configurado contempla soporte para setter (Field.hasSetter == TRUE) ([SWS_CM_00116]). A diferencia del registro Get, el registro de un manejador Set es obligatorio, ya que la implementación del servidor siempre debe validar los nuevos valores de campo procedentes de clientes anónimos (EXP ARAComAPI §5.4.8.2 «Registering Setters»).

En comparación con el registro estándar según [SWS_CM_00116], esta sobrecarga acepta adicionalmente un contexto de ejecución executor de tipo ExecutorT&& ([SWS_CM_11362], [SWS_CM_11360]). Interpretación: Es probable que executor controle en qué contexto de hilo o de planificador de tareas se ejecuta la retrollamada. Pregunta Q-6dec4c0005c388dd (abierta) El manejador pasado posee la signatura std::function<ara::core::Future<FieldType>(<SFieldDerivedType> value)>; recibe el valor establecido por el cliente y devuelve de forma asíncrona a través de ara::core::Future el valor efectivo (en su caso, validado o corregido) ([SWS_CM_11362], EXP ARAComAPI §5.4.8.2 «Registering Setters»).

El Communication Management asume el valor efectivo devuelto por el manejador implícitamente como si la propia aplicación de servidor hubiera invocado Update(); por lo tanto, una invocación manual de Update() dentro del manejador es superflua (EXP ARAComAPI §5.4.8.2 «Registering Setters», EXP ARAComAPI §4.6 «Data Type Abstractions»).

Tratamiento de errores y concurrencia:

• Seguridad frente a excepciones: La función está declarada como noexcept y especificada como segura frente a excepciones (exception safe) ([SWS_CM_11362]).
• Infracciones: Si el ejecutable (callable) pasado setHandler no existe o es nullptr, se produce la infracción InvalidHandlerViolation ([SWS_CM_11362]).
• Contexto: El método garantiza que la ejecución del manejador tenga lugar en el contexto proporcionado de executor ([SWS_CM_11362]).

La función SetTransportFaultConditionHandler sirve para registrar un manejador de errores de tipo ara::com::e2e::TransportFaultConditionHandler para peticiones Get y Set de un campo a nivel de Skeleton en el espacio de nombres <SI-Namespace>::skeleton::fields::<Field> [SWS_CM_00096]. La llamada se ejecuta de forma síncrona, no tiene valor de retorno (void) y garantiza la seguridad frente a excepciones mediante su especificación como noexcept [SWS_CM_00096]. Para escenarios en los que la ejecución del manejador deba delegarse en un contexto de ejecución explícito, se dispone de la sobrecarga de plantilla con un objeto ejecutor ExecutorT&& executor [SWS_CM_00097].

Como condición de error se define la infracción InvalidHandlerViolation; esta se produce cuando el invocable handler proporcionado no existe o es nulo [SWS_CM_00096]. Mientras que en el lado del cliente los errores en peticiones de métodos y campos se notifican mediante ComErrc::kCommunicationFailure en las respectivas instancias ara::core::Future [SWS_CM_00090], esta función permite a la instancia del servidor recibir errores de transporte en llamadas Get y Set entrantes [SWS_CM_00096].

El concepto se corresponde con los correspondientes mecanismos de registro para todos los métodos de una instancia de servicio Skeleton [SWS_CM_00093], así como con los manejadores del lado del proxy para eventos [SWS_CM_00099], activadores [SWS_CM_00106] y notificadores de campo [SWS_CM_00109]. Interpretación: el registro del manejador debería realizarse de forma razonable durante la fase de inicialización previa a la provisión del Skeleton, con el fin de poder capturar sin fisuras los errores en los accesos iniciales al campo. Pregunta Q-627229896b666532 (abierta)

La función SetTransportFaultConditionHandler en el espacio de nombres <SI-Namespace>::skeleton::fields::<Field> registra un gestor de errores para anomalías de transporte en solicitudes Get y Set de un campo en el nivel de Skeleton [SWS_CM_00097]. Se incluye a través del encabezado <SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton.h [SWS_CM_00097].

Uso y parámetros

La llamada se realiza de forma síncrona y no tiene valor de retorno (void) [SWS_CM_00097]. Como parámetros se pasan el callback de error invocable handler de tipo ara::com::e2e::TransportFaultConditionHandler así como una referencia de reenvío executor del tipo genérico ExecutorT&& [SWS_CM_00097]. El parámetro executor designa el objeto de ejecución en cuyo contexto se ejecutan los posibles cómputos asíncronos [SWS_CM_00097].

Tratamiento de errores y concurrencia

El método está declarado como noexcept y garantiza una total seguridad frente a excepciones (exception safe) [SWS_CM_00097]. Si el invocable handler pasado no existe o es null, se desencadena una InvalidHandlerViolation [SWS_CM_00097]. Interpretación: Mediante el objeto executor pasado presumiblemente se determina en qué contexto de hilo o tarea se procesa la notificación asíncrona en caso de errores de transporte. Pregunta Q-4101faaa8d6a3130 (abierta)

Interacción

El método amplía el registro estándar [SWS_CM_00096] con un contexto de ejecución dedicado para campos de Skeleton [SWS_CM_00097]. También existen las correspondientes sobrecargas con ejecutor para métodos de Skeleton ([SWS_CM_00094]), así como en el lado del cliente o Proxy para eventos ([SWS_CM_00100]) y notificadores de campo ([SWS_CM_00110]).

La función UnsetTransportFaultConditionHandler sirve, en el lado esqueleto (skeleton) de una interfaz de servicio, para revocar un ara::com::e2e::TransportFaultConditionHandler registrado previamente para solicitudes get y set de un campo ([SWS_CM_00098]). Está definida en el espacio de nombres <SI-Namespace>::skeleton::fields::<Field> e incluida a través de la cabecera <SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton.h (AUTOSAR_AP_SWS_CommunicationManagement §8.4.3.2.1.3 «UnsetTransportFaultConditionHandler»). La llamada se realiza de forma síncrona, no acepta parámetros de entrada y no proporciona ningún valor de retorno (void).

Mediante la revocación se desactiva la retrollamada específica de la aplicación para estados de error de transporte en solicitudes de campo (AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 «End-to-end communication protection for SOMEIP»). La interfaz está declarada como noexcept y garantiza seguridad frente a excepciones (exception safe) ([SWS_CM_00098]). No se especifican códigos de error ni notificaciones de error específicas a través de DET o DEM; el proceso está concebido para concluir sin errores.

En cuanto a concurrencia y reentrancia, la especificación no contiene directrices específicas. En consecuencia, es de suponer que la desvinculación se realiza preferentemente durante fases de desinicialización o fuera de procesamientos get/set concurrentes para evitar incoherencias en operaciones de comunicación en curso. Pregunta Q-06bc8d90f1891904 (abierta)

La operación forma parte de la protección de la comunicación de extremo a extremo para instancias de servicio (AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 «End-to-end communication protection for SOMEIP»). Constituye la contrapartida relativa a campos de [SWS_CM_00095], que desregistra el manejador para todos los métodos de un esqueleto. En el lado del proxy, se corresponde con las desregistraciones análogas para eventos ([SWS_CM_00105]), disparadores ([SWS_CM_00108]) y notificadores de campo ([SWS_CM_00126]).

El método Update() se invoca en el lado del servidor dentro del ámbito <SI-Namespace>::skeleton::fields::<Field> para actualizar el valor interno de un campo e iniciar la transmisión de los nuevos datos a los clientes suscritos ([SWS_CM_00119], AUTOSAR_AP_EXP_ARAComAPI §4.6 «Data Type Abstractions»). Se envía una notificación a los suscriptores si se ha configurado hasNotifier == TRUE para el campo ([SWS_CM_00119], [SWS_CM_00120], [SWS_CM_00162]). El parámetro value se pasa por referencia; la implementación del binding crea durante la invocación una copia típicamente serializada, de modo que los datos de la aplicación se pueden modificar o liberar en el lado del invocador tras el retorno (AUTOSAR_EXP_ARAComAPI «UpdateRate Class»).

La función está definida como noexcept, así como exception safe, y devuelve de forma síncrona un ara::core::Result<void> ([SWS_CM_00119]). Si se produce un error, el resultado contiene un código de error de ara::com::ComErrc ([SWS_CM_00119], [SWS_CM_10432]). En concreto, se devuelve ComErrc::kMinimumSendIntervalViolationError con semántica de reversión si las solicitudes de envío se producen más rápido de lo especificado por el intervalo mínimo de envío configurado ServiceInterfaceDeploymentElement.minimumSendInterval ([SWS_CM_00119]).

En el ciclo de vida del servicio, se requiere una invocación inicial de Update() antes de ofrecer el servicio: si se invoca OfferService() antes de que se haya inicializado el valor del campo, la puesta a disposición falla con ComErrc::kFieldValueNotInitialized ([SWS_CM_00101], [SWS_CM_00128]). A falta de una garantía explícita de reentrancia en el estándar, es probable que las llamadas simultáneas sobre la misma instancia de campo deban sincronizarse en la aplicación. Pregunta Q-67b174ef05867989 (abierta)