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
DataGroupSpecification (extends DataElementSpecification) Property Type M/O Description Contents Sequence of DataElement M One or more Data Elements contained within this group Table 69: DataGroupSpecification (extends DataElementSpecification) Data Element Formatting Tags The following predefined Data Element formatting tags MAY be used in Data Element Specification (see Section 8.5.11). An Implementation MAY use this information to determine how to display the data. Implementation-specific tags MAY be defined and MUST begin with “X-”. Formatting Tag Description Title Value of the associated Data Element is to be displayed as the title of a Work Request (actual visual interpretation of this tag is implementation specific). Note that this tag may appear in several forms, typically in Header and Overview of Work Request, in which case it is expected that the visualization paradigm used is consistent across all of them. This formatting tag MUST NOT be used for updatable elements Subtitle Like “title”, but visually expressed as an element related to, and further refining the content of element tagged with “title” This formatting tag MUST NOT be used for updatable elements Header The column corresponding to this Data Element SHOULD be visualized as a header in a data matrix Monospace The value of the element SHOULD be displayed with a fixed width font Preformatted The line breaks, if any, present in the value of the element SHOULD be respected and displayed Phonenumber The value of the element is a phone number and, if supported by the device, MAY be used for communication services Weblink The value of the element is a web URL and MAY be displayed as a hyper link Log The associated data matrix SHOULD be displayed as a log of events or data. E.g. usually an ordered list of rows with one column with a key such as a time-stamp, and associated data in other columns. Collapsed The Data element SHOULD be displayed initially in a collapsed view, for example displaying only the label and
extending BatchItemResult operation. See the result entities defined for operations domains. Table 91: BatchOperationResponse If a BatchOperationResponse contains an error code E0000 or E0001 in ErrorCode property of the BaseResponse class then its Results property MUST contain an operation-specific result, derived from the abstract BatchItemResult described in Table 92, for each item specified in the corresponding batch operation request. If an error code other than E0000 or E0001 is returned in ErrorCode property of the BaseResponse class then the Results property SHOULD NOT be included in the response. BatchItemResult (abstract base class) Property Type M/O Description Id Id M Identifier of the item being accessed ErrorCode ErrorCode M Result of per-item operation. Error codes are specified in Section 8.7. Cause String O Optional description of the error or supplementary information for an E0000 (OK) response Table 92: BatchItemResult “Users” Repository Introduction Repository with identifier “Users” contains configuration data necessary to authenticate, authorize and communicate with individual Assignees and administrative users. Type of Values of Reference Data Items stored in the repository MUST be UserProfile. Each profile MUST have a unique identifier, which can consequently be included in Work Requests to indicate work ownership. UserProfiles also contain information required for authentication and authorization purposes. Other data suitable for this registry is description of the type of terminals the Assignee can use, and general or device-specific presets and user preferences. Repository Descriptor User repository MUST use the following standard Repository Descriptor: Id “Users” Description “Catalogue of user profiles” Readable <implementation specific> Writable <implementation specific> CustomProperties <implementation specific>
Revision History Date Editor Changes Made 01 26 August 2011 Thinh Initial draft based on FFMIISpecification-Foundation20110720-D 01 11 2011 Thinh Input from 01 30 2011 Thinh Input from FFMII-Specification-Foundation-20110919-JL-statushandling02 01 06 October, 2011 Thinh Input from FFMII-Specification-Foundation-20110930-v1.0-wd01-IB-20111004 01 12 October, 2011 Thinh Input from Editorial clean up (fixing fonts, references, etc.) 01 26 October, 2011 Thinh Input from FFMII-Specification-Foundation-20111012-v1.0-wd01 FFMII-Specification-Foundation-20111017-v1 0-wd01 Error Codes FFMII-Specification-Foundation-20111017-v1.0-wd01 Protocol
2011 FFMII-Specification-Foundation-201111214-v2.0-wd01-ib-fir 01 19 January 2012 Thinh FFMII-Specification-Foundation-201111214-v4.0-wd01-ib-fir 01 27 January 2012 Thinh 01 14 March 2012 Thinh FFMII-Specification-20120127-v1.0-wd01Clean_JT_Comments_05 01 15 March 2012 Thinh FFMII-Specification-20120127-v1.0-wd01Clean (Section 1 – 8.1.4) 01 22 March 2012 Thinh FFMII-Specification-20120127-v1.0-wd01Clean ThinhComments-03 (Section 8.2 to end) 01 29 March 2012 Thinh FFMII-Specification-20120127-v1.0-wd01Clean-JL-Review-05 01 April 2012 Thinh FFMII-Specification-20120329-v1 0-wd01Thinh clean-up FFMII-Specification-20120315-v1.0-wd01Clean_JuhaActions-02 FFMII-Specification-20120322-v1.0-wd01_JS FFMII-Specification-20120329-v1 0-wd01-JL-20120402-02 FFMII-Specification-20120329-v1_0-wd01-JTSequence 01 11 April 2012 Thinh