Figure 3: Manager-Initiated Work Requests An Implementation MUST support Work Request status polling and it SHOULD support sending of status change notifications. Field-Initiated Interactions FFMII employs Field-Initiated Interactions concept for relying requests initiated by an Assignee in the field and targeting specific functionality inside of ERMS. Such interactions can be used for triggering ERMS actions in the context of specific Work Request, or as request not related to any Work Request in particular. Field-Initiated Requests take form of either Topical Notifications or Topical Inquiries, depending on whether response data is expected for the request in question. Responses to Topical Inquiries are asynchronous, whereby Implementation polls for responses related to the requests it has submitted. Implementation MAY also poll for responses to several Field-Initiated Requests at once. Figure 4 describes Topical Notifications and Topical Inquiries from the data type interaction point of view: Figure 4: Field-Initiated Interactions Note: In the FFMII context, the ultimate receiver of Field-Initiated Requests is the Manager. However, the Manager may also act as a relay agent forwarding requests (in their direct or modified form) to another integrated system, and relaying responses back to Implementation. Integration Topologies FFMII interface offers several ways to integrate Managers and Implementations with each other: Simple topology: a single Manager and a single Implementation interacting Distributed work realization: A single Manager interacting with several Implementations for communicating with distinct groups of field personnel Shared Field Force: multiple Managers interacting with a single Implementation Figure 5 outlines principal differences between each type of integration scenario: Figure 5: Simple and Advanced Integration Topologies In Figure 5 the arrows between Managers and Implementations represent logical links between computing systems of specific roles and different system identity. On the network level, Managers and Implementations MAY access their counter-parts through several networking end-points if needed. Individual integration topologies MUST not exclude each other. For example, a single Manager might be sharing a specific Implementation with another Manager for some Work Requests Field (“shared Force” scenario), while at the same time deploying other Work Requests to another Implementation (“distributed
Figure 3: Manager-Initiated Work Requests An Implementation MUST support Work Request status polling and it SHOULD support sending of status change notifications. Field-Initiated Interactions FFMII employs Field-Initiated Interactions concept for relying requests initiated by an Assignee in the field and targeting specific functionality inside of ERMS. Such interactions can be used for triggering ERMS actions in the context of specific Work Request, or as request not related to any Work Request in particular. Field-Initiated Requests take form of either Topical Notifications or Topical Inquiries, depending on whether response data is expected for the request in question. Responses to Topical Inquiries are asynchronous, whereby Implementation polls for responses related to the requests it has submitted. Implementation MAY also poll for responses to several Field-Initiated Requests at once. Figure 4 describes Topical Notifications and Topical Inquiries from the data type interaction point of view: Figure 4: Field-Initiated Interactions Note: In the FFMII context, the ultimate receiver of Field-Initiated Requests is the Manager. However, the Manager may also act as a relay agent forwarding requests (in their direct or modified form) to another integrated system, and relaying responses back to Implementation. Integration Topologies FFMII interface offers several ways to integrate Managers and Implementations with each other: Simple topology: a single Manager and a single Implementation interacting Distributed work realization: A single Manager interacting with several Implementations for communicating with distinct groups of field personnel Shared Field Force: multiple Managers interacting with a single Implementation Figure 5 outlines principal differences between each type of integration scenario: Figure 5: Simple and Advanced Integration Topologies In Figure 5 the arrows between Managers and Implementations represent logical links between computing systems of specific roles and different system identity. On the network level, Managers and Implementations MAY access their counter-parts through several networking end-points if needed. Individual integration topologies MUST not exclude each other. For example, a single Manager might be sharing a specific Implementation with another Manager for some Work Requests (“shared Field Force” scenario), while at the same time deploying other Work Requests to another Implementation (“distributed
FFMII-Specification-20120411-v1%200-wd01-SV-WSDL-review.docx