Issues for Alerts Management Service 1.0 (ALMAS) Finalization Task Force
To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 12287: Section 2.1 Jira Issue ALMAS-2
Issue 12288: 2.2 Conformance requirements Jira Issue ALMAS-3
Issue 12289: 2.3.1 ALMAS Client Callbacks Jira Issue ALMAS-4
Issue 12290: 2.3 General Jira Issue ALMAS-5
Issue 12291: Section 2.3.1 & 2 Jira Issue ALMAS-6
Issue 12292: Section 2.3.2.1 Jira Issue ALMAS-7
Issue 12293: 2.3.2.1 Jira Issue ALMAS-8
Issue 12294: 2.3.2.3 AlertDataExtraAttributes Jira Issue ALMAS-9
Issue 12295: 2.3.2.8 DataTag Jira Issue ALMAS-10
Issue 12296: 2.3.3.1.1 ReceiverKind Operations Jira Issue ALMAS-11
Issue 12986: ALMAS Template Alert Data specification schema - Current schema only allows one Alert Template per XML file Jira Issue ALMAS-12
Issue 12987: Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length" Jira Issue ALMAS-13
Issue 12988: ALMAS DCOM IDL corrections: Sections 2.8.11 & 2.8.1.3 Jira Issue ALMAS-14
Issue 12989: Section 2.8.1.3 Jira Issue ALMAS-15
Issue 12990: Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter Jira Issue ALMAS-16
Issue 12991: Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides Jira Issue ALMAS-17
Issue 12992: Section 2.6.1.1 ALMAS_DataModel.idl Jira Issue ALMAS-18
Issue 12993: Sections 2.6.1.3, 2.7.4.2, 2.8.1.3 Jira Issue ALMAS-19
Issue 12994: 2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs Jira Issue ALMAS-20
Issue 13013: ALMAS configuration files contain not valid xsd constructs Jira Issue ALMAS-21
Issue 13014: Method GetAllTemplateIDs of ALMASManager not mapped Jira Issue ALMAS-22
Issue 13015: Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides) Jira Issue ALMAS-23
Issue 13016: priority attribute value Jira Issue ALMAS-24
Issue 13017: Attribute TimeoutAction Jira Issue ALMAS-25
Issue 13018: ALMASReceiver.stateChangeNotification(int, Enumeration) Jira Issue ALMAS-26
Issue 13019: Catgorisation rules Jira Issue ALMAS-27
Issue 13020: DynamicMessageData instances Jira Issue ALMAS-28
Issue 13021: RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert). Jira Issue ALMAS-29
Issue 13022: mapping a number of methods Jira Issue ALMAS-30
Issue 13024: Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01 Jira Issue ALMAS-31
Issue 13025: Removal of alerts is not clearly addressed in the spec Jira Issue ALMAS-32
Issue 13026: UpdateAlert not useful, so remove it from the spec Jira Issue ALMAS-33
Issue 13027: Consistently start methods with capitals (or not). Jira Issue ALMAS-34
Issue 13028: Operation Unregister should be UnregisterReceiver Jira Issue ALMAS-35
Issue 13029: Enable receiver hierarchy per alert template? Jira Issue ALMAS-36
Issue 13030: Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType? Jira Issue ALMAS-37
Issue 13032: Section 6.3.6: RegisterReceiver Jira Issue ALMAS-38
Issue 13033: Section 6.2, 7.1: Name inconsistency Jira Issue ALMAS-39
Issue 13034: ALMAS - IDL COM Corrections - Use SAFEARRAYs instead of the UDT array types ...TypeSet Jira Issue ALMAS-40
Issue 13037: Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction Jira Issue ALMAS-41
Issue 13042: ConfirmReceipt contains parameter ReceiverID Jira Issue ALMAS-42
Issue 13169: Definition and behaviour of AlertDistributionNotification is not consistent Jira Issue ALMAS-43
Issue 13170: Type of element name "Tag" not correct Jira Issue ALMAS-44
Issue 13171: Operation RaiseAlertFromOverrides Jira Issue ALMAS-45
Issue 13172: Operation RaiseAlertFromOverrides Jira Issue ALMAS-46
Issue 13173: Operation Operation RemoveAlertsWithDynamicMessageData: Jira Issue ALMAS-47
Issue 13174: Struct ALMAS_GetFilledMessageText Jira Issue ALMAS-48
Issue 13175: In the PIM, when creating an Alert ( RaiseAlertFrom...) Jira Issue ALMAS-49
Issue 13176: Topic GetFilledMessageText needs ReceiverID attribute Jira Issue ALMAS-50
Issue 12287: Section 2.1 (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary:
This section seems to be misplaced. It is a table without headings or other explanations
Resolution:
Revised Text:
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Discussion: This section was removed as part of the Beta 1 production Disposition: Closed, no change
Issue 12288: 2.2 Conformance requirements (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: - Conformance level 0 seems to me so weak that it may actually detract from the specification, i.e., the ability to conform at level 0 is so easy that it is not clear that any vendor would invest in Level 1 conformance. - The statement in clause c) seems not to capture the intended conformance options. In our discussions, I think we agreed that we need an explicit list of optional conformance points and a statement of the ability to independently conform to each.
Resolution: Replace all text in section 2 of beta 1 with the following revised text.
Revised Text: This specification provides a single level of conformance that defines the minimum functionality required of any ALMAS implementation. This is defined as follows: � PSM level conformance. An ALMAS achieving conformance level 1 conforms to one or more of the middleware platform specific models presented in Chapters 8, 9 and 10 of this document in addition to conforming to the XML Alert template data model and the XML initialization PSMs as presented in sections 7.1 to 7.3 of this document. In addition the specification identifies a number of classes (postfixed with 'Extensions') together with the categorization PIM and PSM in sections 6.4 and 7.4 which define additional, optional functionality. These can be provided in any combination of the following four options: 1 - Support for additional alert cancellation options ALMASManagerExtensions RemoveAlertsWithDynamicMessageData 2 - Support for categorisation rules ALMASManagerExtensions AttachCategorisationRule + DetachCategorisationRule +ALMAS Categorisation Rule XML schema 3 - Support for more than one language ALMASResponderExtensions SetLanguage 4 - Complete AlertReport text tag subsitution ALMASResponderExtensions GetFilledMessageText
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Issue 12289: 2.3.1 ALMAS Client Callbacks (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: ALMAS Client Callbacks (comment on a previous version that has not been addressed) Package names or parts of the package names are reused and redundant within the class name. Examples include ALMAS::Client Callbacks::ALMASReceiver and ALMAS::Client Callbacks::ALMASNotificationListener
Resolution: Removed the redundant names. Replace section 10.3 with the following IDL (changes annotated with comments):
Revised Text: // Copyright 2005-2008 THALES, BAE Systems, Raytheon import "../Alert_Data_Router/ALMAS_DataModel.idl"; #ifndef __ALMAS_Client_DEF #define __ALMAS_Client_DEF [object,uuid(13D0EBD4-47C0-4661-BFF6-B8220219BD66), pointer_default(unique)] interface IALMAS_Receiver: IUnknown { HRESULT Client_StateChangeNotification ( // Issue 12289 - removed ALMAS prefix [in] ALMAS_AlertIDType AlertID, [in] ALMAS_StateType NewState); HRESULT Client_AlertDataNotification (// alert ID is embedded within info - Issue 12289 - remove ALMAS prefix [in] ALMAS_Alert AlertInfo, [out] ALMAS_AlertReportType *Report); // Issue 12994 need to add callbacks for data returned as a result of calls to _get_ALMAS_SystmID, GetAlert, // GetAlerts, GetTemplate and GetTemplateIDs HRESULT _get_ALMAS_SystemIDNotification ( [out] BSTR * ALMAS_SystemID); HRESULT GetAlert_Notification( [out] ALMAS_Alert *Alert); HRESULT GetAlertsNotification( [out] SAFEARRAY(ALMAS_Alert)*AlertSet); HRESULT GetTemplateNotification( [out] ALMAS_TemplateIDType *AlertTeplate); HRESULT GetTemplatesNotification( [out] SAFEARRAY(ALMAS_TemplateIDType) *TemplateIDSet); }; [object,uuid(2BA3B7FA-40EB-4021-8828-36243C457379), pointer_default(unique)] interface IALMAS_NotificationListener: IUnknown { HRESULT AlertDistributionNotification ( [in] ALMAS_AlertIDType AlertID, [in] ALMAS_CallStatus Status); }; #endif
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Issue 12290: 2.3 General (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: the descriptions of the model elements are not sufficient. For example, the description of ALMASNotificationListener is "Class provided by registering notification listeners for receipt of alert distribution notifications", which is not much more descriptive than the name of the class
Resolution: Included significantly more descriptive text in the model section of the specification. Section 6, 6.1, 6.2, 6.3 affected significantly. Edited text supplied as additional change-barred document, attached. Note that this issue should be applied FIRST, there are some additional changes to the text in section 6 which should be applied after this issue.
Revised Text: See convenience document dtc-2009-03-07.
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Issue 12291: Section 2.3.1 & 2 (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: It is real error that there is no relationship (including possibly a derivation) between AvailableAlertReceiver and ALMASReceiver. A link by a string name doesn't allow type-safe technology to check the proper provision of a ALMASReceiver as a available receiver.
Resolution: No change to the model has been made. The following additional text has been added to section 6.2.6 (as part of resolution of issue 12290): '�through the ReceiverID attribute, which is provided at registration time to ALMAS using the RegisterReceiver method.'
Revised Text: Covered by changes for 12290
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Issue 12292: Section 2.3.2.1 (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: The description of Alert has the text: "The message text is not fully filled in here." This looks like an editorial comment.
Resolution:
Revised Text:
Actions taken:
March 14, 2008: received issue
April 30, 2009: Disposition: See issue 12290 for disposition
July 23, 2009: closed issue
Issue 12293: 2.3.2.1 (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: The text for the attribute CurrentState implies that there is a constraint between the allowed values and the category of the alert. These constraints need to be formally captured, e.g., through OCL.
Resolution: Update the model as described below and the text in section 6.2.1.: 1) give a name to association between Alert and Alert Data on AlertData end of "alert_data" 2) include an OCL constraint for this: "context a: Alert inv: if ((a.alert_data.Category = Information) or (a.alert_data.Category = Warning))) then (a.CurrentState <> Handled)" Documentation changes required to section 6.2.1 description for current state in attributes table to append 'Note that Handled is not a valid state for Information and Warning Alerts.' Figure 6.2 requires update to show the constraint.
Revised Text: Changes supplied as part of 12290 changes. Model updates supplied in ALMAS model FTF xmi.
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Issue 12294: 2.3.2.3 AlertDataExtraAttributes (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: This section provides an extension mechanism for AlertData so that this data can safely be transferred to products that don't understand the extensions. The requirements that receipt of any of this data not be "dropped" etc. need to be clarified. Also, there should be the possibility for providing a "type" indication (possibly either a string or enumeration) that would allow different products to interpret different extensions.
Resolution: Need to update Figure 6.2 and 6.2.3 AlertDataExtraAttributes attributes table: 1) add attribute "TypeOfByteData" of type int, with the description of "Valid values for this are: 0 = string 1 = Integer8 2 = Integer16 3 = Integer32 4 = Float32 5 = Float64 6 = bytes" 2) add attribute "Description" of type string with description "Used to provide indicaton of the content e.g. "image (jpg)", "URL", "track object", ..." Replace the last sentence of the AlertDataExtraAttributes description 'The extra attributes are configured via the ALMAS Alert definition xml PSM specified in section 7.1. If defined in the Alert definition XML provided to ALMAS, then ALMAS shall support the definition, receipt, storage and passing of this data to receivers as part of a standard implementation.'
Revised Text: The changes for section 6.2.3 are covered by the resolution of issue 12290. Insert in section 7.1 is as follows: <xs:complexType name="Alert_Data_Extra_Attributes_T"> <xs:sequence> <xs:element name="Name"> <xs:simpleType> <xs:annotation> <xs:documentation>The Attribute Name</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="TypeOfByteData"> <xs:simpleType> <xs:annotation> <xs:documentation>Flag to indicate the type of data</xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Description"> <xs:simpleType> <xs:annotation> <xs:documentation>Description of contents e.g. image(jpg), URL, Track report etc</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> The changes to the IDL file for section 8.2 is as follows: struct ALMAS_AlertDataExtraAttributesType { string Name; short TypeOfByteData; string Description; ALMAS_ByteSequence Value; }; The changes to the IDL file for section 9.2 is as follows: struct ALMAS_AlertDataExtraAttributesType { string Name; short TypeOfByteData; string Description; ALMAS_ByteSequence Value; }; The changes to the IDL file for section 10.2 is as follows: typedef [uuid(F42A96DE-F513-4880-8E5A-5C2B308A2898)]struct ALMAS_AlertDataExtraAttributesType{ BSTR Name; // Issue 12988 - LPSTR now BSTR short TypeOfByteData; BSTR Description; SAFEARRAY(byte) Value; } ALMAS_AlertDataExtraAttributesType;
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Discussion:
Issue 12295: 2.3.2.8 DataTag (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: the format of this string needs to be specified so that different products can parse it consistently and thus can interoperate.
Resolution: Clarify format of the string. Update 6.2.10 table description for MessageText: This is a text string, which in an Alert or AlertTemplate is only partially completed. With the MessageText being "xxxxx %t1 yyyyyyy zzzz" in an Alert or AlertTemplate, and with a DynamicMessageData with DataTag having the value 't1' and DataValue having the value '123' then the resulting MessageText in response to GetFilledMessageText will be 'xxxxx 123 yyyyyyy zzzz'. All substitution points are bracketed by use of "<space>%" and <space>, and are case sensitive, alphanumeric strings ("t1" in the above) which should correspond to a DataTag in an associated DynamicMessageData. Update text for DataTag in 6.2.8: This identifies the insertion point for the related object in the MessageText associated with the Alert. I.e. where the MessageText is "xxxxx %t1 yyyyyyy zzzz", then DataTag has the value 't1'. It is a case sensitive, alphanumeric string
Revised Text: Changes have been carried out as identified above in the resolution of issue 12290.
Actions taken:
July 23, 2009: closed issue
March 21, 2048: received issue
Issue 12296: 2.3.3.1.1 ReceiverKind Operations (almas-ftf)
Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary: Each of these operations, in fact, only work with an XML file that conforms to a particular XSD, which is defined later in the specification. This needs to be made explicit
Resolution: 6.3.1 table row entries need updating to reflect the XML file linkages.
Revised Text: Changes already made as part of issue 12290 resolution.
Actions taken:
March 14, 2008: received issue
July 23, 2009: closed issue
Issue 12986: ALMAS Template Alert Data specification schema - Current schema only allows one Alert Template per XML file (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Current schema only allows one Alert Template per XML file. Correct to allow more than one alert.
Resolution:
Revised Text:
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Discussion: The comment was made against an old version of the XML. Disposition: Closed, no change
Issue 12987: Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length" (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length" for the Text variable data to aid sizing the final text when attempting to expand the dynamic text.
Resolution:
Revised Text:
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Discussion: Review of the comment resulted in there being no need for the additional parameter. Disposition: Closed, no change
Issue 12988: ALMAS DCOM IDL corrections: Sections 2.8.11 & 2.8.1.3 (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Sections 2.8.11 & 2.8.1.3 LPSTR types should be changed to BSTR (automation type).
Resolution: Agreed - this affect the DCOM IDL files in sections 10.2, 10.3, 10.4.
Revised Text: he changed version of the IDL file for section 10.2 is as follows: // Copyright 2005-2007 THALES, BAE Systems, Raytheon // Issue 12988 Start - allow use of BSTR type. import "oaidl.idl"; import "ocidl.idl"; // Issue 12988 End #ifndef __ALMAS_DataModel_DEF #define __ALMAS_DataModel_DEF typedef long ALMAS_AlertIDType; typedef long ALMAS_TemplateIDType; typedef long ALMAS_TimeoutType; #ifdef NOLONGLONG typedef struct { unsigned long low; unsigned long high; } ALMAS_DateTimeType; #else typedef unsigned long long ALMAS_DateTimeType; // long long to be EVoT compatible #endif // typedef long long ALMAS_DateTimeType; // long long to be EVoT compatible // Issue 13034 - now using safearray // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] byte *pValue;} ALMAS_ByteSequence; // Issue 13034 - now using safearray // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] BSTR Value;} ALMAS_StringSet; // Issue 12992 typedef enum { ALMAS_Action = 1, ALMAS_Warning, ALMAS_Information, ALMAS_Situation} ALMAS_CategoryType; // Issue 12992 typedef enum { ALMAS_Raised = 1, ALMAS_Routed, ALMAS_Received, ALMAS_Acknowledged, ALMAS_Handled, ALMAS_Cancelled, ALMAS_TimedOut} ALMAS_StateType; // Issue 13017 // Issue 12992 typedef enum { ALMAS_Actual = 1, ALMAS_Exercise, ALMAS_System, ALMAS_Test} ALMAS_StatusType; // Issue 12992 typedef enum { ALMAS_PublicScope = 1, ALMAS_RestrictedScope, ALMAS_PrivateScope} ALMAS_ScopeType; // Issue 12992 typedef enum { ALMAS_CancelOnly = 1, ALMAS_NotifyOnly, ALMAS_CancelWithNotify} ALMAS_TimeoutActionType; // Issue 12992 typedef enum { ALMAS_AckByNone = 1, ALMAS_AckByAnyone, ALMAS_AckByAll} ALMAS_AckModelType; typedef struct { boolean Success; short Reason; BSTR Description;} ALMAS_CallStatus; // Issue 12988 - LPSTR now BSTR typedef struct { SAFEARRAY(BSTR) AlternativeAction; // Issue 12988 - LPSTR now BSTR & Issue 13037 now safearray short ActioneePriority; } ALMAS_ValidAlertResponseType; typedef [uuid(0B7DF643-8DFF-4cfe-BC48-3C2E07BD6A79)]struct ALMAS_ReceiverKindType { BSTR RKType; // Issue 12988 - LPSTR now BSTR BSTR RKParentType; // Issue 12988 - LPSTR now BSTR ALMAS_ValidAlertResponseType ValidResponse; } ALMAS_ReceiverKindType; // Issue 13034 - now redundant type so could be deleted. // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_ReceiverKindType *pValue;} ALMAS_ReceiverKindTypeSet; typedef [uuid(62FD9C37-ED08-46b2-8122-8B783D83DC5E)] struct ALMAS_DynamicMessageDataType{ BSTR DataType; // Issue 12988 - LPSTR now BSTR BSTR DataTag; // Issue 12988 - LPSTR now BSTR BSTR DataValue; } ALMAS_DynamicMessageDataType; // Issue 12988 - LPSTR now BSTR // Issue 13034 - now redundant type so could be deleted. // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_DynamicMessageDataType *pValue;} ALMAS_DynamicMessageDataTypeSet; typedef [uuid(06A4B73D-52AD-4009-BC0A-4FC940D3A799)]struct ALMAS_StaticMessageType{ BSTR MessageText; // Issue 12988 - LPSTR now BSTR BSTR MessageLanguage; } ALMAS_StaticMessageType; // Issue 12988 - LPSTR now BSTR // Issue 13034 - now redundant type so could be deleted. // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_StaticMessageType *pValue;} ALMAS_StaticMessageTypeSet; typedef [uuid(F42A96DE-F513-4880-8E5A-5C2B308A2898)]struct ALMAS_AlertDataExtraAttributesType{ BSTR Name; // Issue 12988 - LPSTR now BSTR short TypeOfByteData; BSTR Description; SAFEARRAY(byte) Value; } ALMAS_AlertDataExtraAttributesType; // Issue 13034 - now safearray // Issue 13034 - now redundant type so could be deleted. // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_AlertDataExtraAttributesType *pValue;} ALMAS_AlertDataExtraAttributesTypeSet; typedef struct { ALMAS_TemplateIDType TemplateID; ALMAS_CategoryType Category; short Priority; ALMAS_StatusType Status; ALMAS_ScopeType Scope; ALMAS_TimeoutType Timeout; boolean ConfirmationRequired; BSTR SecondaryGrouping; // Issue 12988 - LPSTR now BSTR boolean Persistent; boolean ReliablyDistributed; ALMAS_TimeoutActionType TimeoutAction; ALMAS_AckModelType AcknowledgementModel; SAFEARRAY(ALMAS_StaticMessageType) StaticMessages; // Issue 13034 - now safearray SAFEARRAY(ALMAS_DynamicMessageDataType)DynamicMessages; // Issue 13034 - now safearray SAFEARRAY(ALMAS_AlertDataExtraAttributesType) ExtraAttributes;} ALMAS_AlertDataType; // Issue 13034 - now safearray typedef struct { boolean Inhibited; boolean RaiseToAll; ALMAS_AlertDataType AlertData; SAFEARRAY(ALMAS_ReceiverKindType) ReceiverKinds; } ALMAS_AlertTemplateType; // Issue 13034 - now safearray typedef struct { boolean Acknowledged; boolean Routed; boolean Actioned; boolean ReceiverIsActionee; SAFEARRAY(BSTR) AlternativeAction; // Issue 12988 - LPSTR now BSTR // Issue 13037 - now safearray BSTR ReceiverID; // Issue 12988 - LPSTR now BSTR ALMAS_AlertIDType AlertID; } ALMAS_AlertReportType; typedef struct { BSTR ReceiverID; // Issue 12988 - LPSTR now BSTR ALMAS_ReceiverKindType ReceiverKind; } ALMAS_AvailableAlertReceiverType; // Issue 13034 - now redundant type so could be deleted. // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_AvailableAlertReceiverType *pValue; } ALMAS_AvailableAlertReceiverTypeSet; typedef struct { ALMAS_AlertIDType AlertID; ALMAS_DateTimeType RaisingTime; ALMAS_StateType CurrentState; BSTR ProducerID; // Issue 12988 - LPSTR now BSTR ALMAS_AlertDataType AlertData; SAFEARRAY(ALMAS_AvailableAlertReceiverType) Receivers; } ALMAS_Alert; // Issue 13034 - now safearray #endif The changed version of the IDL file for section 10.3 is as follows: // Copyright 2005-2008 THALES, BAE Systems, Raytheon import "../Alert_Data_Router/ALMAS_DataModel.idl"; #ifndef __ALMAS_Client_DEF #define __ALMAS_Client_DEF [ object, uuid(13D0EBD4-47C0-4661-BFF6-B8220219BD66), pointer_default(unique) ] interface IALMAS_Receiver: IUnknown { HRESULT StateChangeNotification ( // Issue 12289 - removed ALMAS_Client_ prefix [in] ALMAS_AlertIDType AlertID, [in] ALMAS_StateType NewState); HRESULT AlertDataNotification (// alert ID is embedded within info - Issue 12289 - remove ALMAS_Client prefix [in] ALMAS_Alert AlertInfo, [in] ALMAS_AlertReportType *Report); // changed to in in. }; [object,uuid(2BA3B7FA-40EB-4021-8828-36243C457379),pointer_default(unique)] interface IALMAS_NotificationListener: IUnknown { HRESULT AlertDistributionNotification ( [in] ALMAS_AlertIDType AlertID); // Issue 12990 REMOVED status parameter [in] ALMAS_CallStatus Status); // Issue 12994 Start - moved callbacks to here and chnaged out to be in parameter. // Issue 12994 need to add callbacks for data returned as a result of calls to _get_ALMAS_SystmID, GetAlert, GetAlerts, GetTemplate and GetTemplateIDs // Suggested methods as below:- HRESULT Get_ALMAS_SystemIDNotification ( // Issue 13027 [in] BSTR * ALMAS_SystemID); // Issue 12994 - now in parameter HRESULT GetAlertNotification( [in] ALMAS_Alert Alert); HRESULT GetAlertsNotification( [in] SAFEARRAY(ALMAS_Alert)AlertSet); HRESULT GetTemplateNotification( [in] ALMAS_AlertTemplateType AlertTemplate); // Corrected to return the template, not the Template ID. HRESULT GetTemplatesNotification( [in] SAFEARRAY(ALMAS_TemplateIDType) TemplateIDSet); // Issue 12994 End }; #endif The changed version of the IDL file for section 10.4 is as follows: // Copyright 2005-2008 THALES, BAE Systems, Raytheon import "../Alert_Data_Router/ALMAS_Client.idl"; import "../Alert_Data_Router/ALMAS_DataModel.idl"; #ifndef __ALMAS_Management_DEF #define __ALMAS_Management_DEF // Issue 13034 - now using safearray // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_Alert *pValue;} ALMAS_AlertSet; // typedef struct { // unsigned long MaxSize; // unsigned long LengthUsed; // [size_is(MaxSize), length_is(LengthUsed), unique] ALMAS_TemplateIDType *pValue;} ALMAS_TemplateIDTypeSet; [object,uuid(3BC17616-F798-421A-8FB9-DDC0A8259CE3),pointer_default(unique)] interface IALMAS_Manager : IUnknown { HRESULT Get_ALMAS_SystemID(IALMAS_NotificationListener *Handle); // Issue 12994 / 13027 // Issue 12994 removed method HRESULT _put_ALMAS_SystemID ([in] [out] BSTR ALMAS_SystemID); // Issue 12988 & 12989 - LPSTR * now BSTR also in out not in // alert retrieval methods HRESULT GetAlert ( [in] ALMAS_AlertIDType AlertID, [in] IALMAS_NotificationListener *Handle, // Issue 12994 [out] ALMAS_CallStatus *CallStatus); // Issue 12990 HRESULT GetAlerts ( [in] BSTR Filter, // Issue 12988 - LPSTR now BSTR [in] IALMAS_NotificationListener *Handle, // Issue 12994 [out] ALMAS_CallStatus *CallStatus); // Issue 12990 // ALMAS-wide control methods HRESULT SetAlertInhibited ( [out] ALMAS_CallStatus *CallStatus, // Issue 12990 [in] ALMAS_TemplateIDType TemplateID, [in] boolean Inhibition); HRESULT UpdateDynamicMessageData ( [out] ALMAS_CallStatus *CallStatus, // Issue 12990 [in] ALMAS_AlertIDType AlertID, [in] BSTR ObjectValue, // Issue 12988 - LPSTR now BSTR [in] ALMAS_DynamicMessageDataType OldValue); HRESULT RegisterNotificationListener ( [out] ALMAS_CallStatus *CallStatus, // Issue 12990 [in] IALMAS_NotificationListener *Handle); // Template management methods HRESULT GetTemplate ( [in] IALMAS_NotificationListener *Handle, // Issue 12994 [in] ALMAS_TemplateIDType TemplateID, [out] ALMAS_CallStatus *CallStatus); // Issue 12990 HRESULT GetAllTemplateIDs ( [out] ALMAS_CallStatus *CallStatus, // Issue 12990 [in] BSTR Filter, // Issue 12988 - LPSTR now BSTR [in] IALMAS_NotificationListener *Handle); // Issue 12994 }; [object,uuid(6AE3866D-3EF5-4BBD-B2ED-261DBCFF2307),pointer_default(unique)] interface IALMAS_ManagerExtensions : IALMAS_Manager { HRESULT RemoveAlertsWithDynamicData ( [out] ALMAS_CallStatus *CallStatus, [in] BSTR CancellerID, // Issue 12988 - LPSTR now BSTR [in] BSTR DataType, // Issue 13173 ALMAS_DynamicMessageDataType ObjectInfo); [in] BSTR DataValue); // Issue 13173 HRESULT AttachCategorisationRule ( [out] ALMAS_CallStatus *CallStatus, // Issue 12990 [in] ALMAS_TemplateIDType TemplateID, // Issue 13019 ALMAS_AlertIDType AlertID, [in] long RuleID); HRESULT DetachCategorisationRule ( [out] ALMAS_CallStatus *CallStatus, // Issue 12990 [in] ALMAS_TemplateIDType TemplateID, // Issue 13019 ALMAS_AlertIDType AlertID, [in] long RuleID); }; [object,uuid(32033A16-EC76-4AC5-A457-D607B5CFD0CF),pointer_default(unique)] interface IALMAS_Producer : IUnknown { // SDG Changed optional parameters to pointers HRESULT RaiseAlertFromOverrides ( [out] ALMAS_AlertIDType *AlertID, [in] BSTR ProducerID, // Issue 12988 - LPSTR now BSTR [in] ALMAS_TemplateIDType TemplateID, [in] ALMAS_CategoryType Category, [in] boolean ValidCategory [in] short Priority, [in] boolean ValidPriority, [in] ALMAS_StatusType AlertStatus, [in] boolean ValidStatus, [in] ALMAS_ScopeType Scope, [in] boolean ValidScope, [in] ALMAS_TimeoutType Timeout, [in] boolean ValidTimeout, [in] boolean ConfirmationRequired, [in] boolean ValidConfirmationRequired, [in] BSTR SecondaryGrouping, [in] boolean ValidSecondaryGrouping, [in] boolean Persistent, [in] boolean ValidPersistent, [in] boolean ReliablyDistributed, [in] boolean ValidReliablyDistributed, [in[ ALMAS_TimeoutActionType TimeoutAction, [in] boolean ValidTimeoutAction, [in] ALMAS_AckModelType AcknowledgementModel, [in] boolean ValidAcknowledgementModel, [in] SAFEARRAY(ALMAS_StaticMessageType) StaticMessages, [in] boolean ValidStaticMessages, [in] SAFEARRAY(ALMAS_DynamicMessageDataType) DynamicMessageData, [in] boolean ValidDynamicMessageData, [in] SAFEARRAY(ALMAS_ReceiverKindType) AlertReceivers, [in] boolean ValidAlertReceiverSet, [out] ALMAS_CallStatus *CallStatus); // Issue 12990 HRESULT RaiseAlertFromData ( [out] ALMAS_AlertIDType *AlertID, [in] BSTR ProducerID, // Issue 12988 - LPSTR now BSTR [in] ALMAS_AlertTemplateType AlertInfo, //Issue 13015 [out] ALMAS_CallStatus *CallStatus); // Issue 12990 HRESULT RaiseAlertFromTemplate ( [out] ALMAS_AlertIDType *AlertID, [in] BSTR ProducerID, // Issue 12988 - LPSTR now BSTR [in] ALMAS_TemplateIDType TemplateID, [out] ALMAS_CallStatus *CallStatus); // Issue 12990 HRESULT UpdateAlertPriority ( [out] ALMAS_CallStatus *CallStatus, [in] ALMAS_AlertIDType AlertID, [in] BSTR ProducerID, // Issue 12988 - LPSTR now BSTR [in] short Priority); //Issue 13026 HRESULT CancelAlert ( [out] ALMAS_CallStatus *CallStatus, [in] ALMAS_AlertIDType AlertID, [in] BSTR CancellerID, // Issue 12988 - LPSTR now BSTR [in] BSTR CancellationReason); // Issue 12988 - LPSTR now BSTR }; [object,uuid(BA617DFD-6DBD-4F08-ACD5-E7F489A113E5),pointer_default(unique)] interface IALMAS_Responder : IUnknown { HRESULT RegisterReceiver ( [out] ALMAS_CallStatus *CallStatus, [in] IALMAS_Receiver *ReceiverHandle, [in] BSTR *ReceiverID, [in] BSTR RKType); HRESULT UnregisterReceiver ( // Issue 13028 [out] ALMAS_CallStatus *CallStatus, [in] BSTR ReceiverID); // Issue 12988 - LPSTR now BSTR HRESULT AcknowledgeAlert ( [out] ALMAS_CallStatus *CallStatus, [in] ALMAS_AlertIDType AlertID, [in] BSTR ReceiverID); // Issue 12988 - LPSTR now BSTR HRESULT HandleAlert ( [out] ALMAS_CallStatus *CallStatus, [in] ALMAS_AlertIDType AlertID, [in] BSTR ReceiverID); // Issue 12988 - LPSTR now BSTR HRESULT ConfirmReceipt ( [out] ALMAS_CallStatus *CallStatus, [in] ALMAS_AlertIDType AlertID, [in] BSTR ReceiverID); // Issue 12988 - LPSTR now BSTR }; [object,uuid(CC748587-4926-45D7-B52E-4A88000A3426),pointer_default(unique)] interface IALMAS_ResponderExtensions : IALMAS_Responder { HRESULT SetLanguage ( [out] ALMAS_CallStatus *CallStatus, [in] BSTR ReceiverID, // Issue 12988 - LPSTR now BSTR [in] BSTR Language); // Issue 12988 - LPSTR now BSTR HRESULT GetFilledMessageText ( [out] ALMAS_CallStatus *CallStatus, [in] ALMAS_AlertIDType AlertID, [in] [out] BSTR MessageText); // Issue 12988 & 12989 - LPSTR now BSTR - now "in out" not "out" }; [object,uuid(C3B50C13-8124-4A5F-98B8-9C68D9D1BDE9),pointer_default(unique)] interface IALMAS_Configuration : IUnknown { HRESULT LoadReceiverHierarchy ( [out] ALMAS_CallStatus *CallStatus, [in] BSTR Filename); // Issue 12988 - LPSTR now BSTR HRESULT LoadTemplateSet ( [out] ALMAS_CallStatus *CallStatus, [in] BSTR Filename); // Issue 12988 - LPSTR now BSTR HRESULT LoadConfiguration ( [out] ALMAS_CallStatus *CallStatus, [in] BSTR Filename); // Issue 12988 - LPSTR now BSTR }; #endif
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 12989: Section 2.8.1.3 (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: _put_ALMAS_SystemID - parameter changed to "in out" instead of "in" because of compiler limitation for parameter type BSTR. GetFilledMessageText - parameter MessageText changed to "in out" instead of "out" - compiler limitation for type BSTR.
Resolution: Remove put_ALMAS_System_ID this is not intended to be alterred by the ALMAS user.
Revised Text: Updated IDL for section 10.4 as in issue 12988:
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 12990: Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter. Some methods define it as CallStatus, others as Status. Suggest we change methods which define the parameter as Status to CallStatus.
Resolution: Carry out the change for section 8.3, 10.3, 10.4 as in attached IDL. For section 6.1.1 remove Status from the parameters
Revised Text: Changes to 6.1.1 covered by 12290 changes. Replace IDL files for section 8.3 with below: // Copyright 2005-2008 THALES, BAE Systems, Raytheon #include "ALMAS_DataModel.idl" #ifndef __ALMAS_Client_DEF #define __ALMAS_Client_DEF #pragma prefix "omg.org" module ALMAS_Client { interface ALMAS_Receiver { oneway void StateChangeNotification ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in ALMAS_DataModel::ALMAS_StateType NewState); oneway void AlertDataNotification ( // alert ID is embedded within info in ALMAS_DataModel::ALMAS_Alert AlertInfo, in ALMAS_DataModel::ALMAS_AlertReportType Report); }; interface ALMAS_NotificationListener { oneway void AlertDistributionNotification ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID); }; }; #endif Updated IDL for section 9.3.2 as in issue 13015. Updated IDL for section 10.4 as in issue 12988:
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 12991: Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides - optional parameters are not supported in C++ as defined in version 7 page 37 for this method. 'Optional' parameters can be supported if the parameters are changed to pointers. Parameters that are not required can then be passed in as NULL.
Resolution: Propose that the method is amended to include a 'valid' indicator for each optional parameter in the PSMs.
Revised Text: Replace IDL files for sections 8.4 with below: // Copyright 2005-2008 THALES, BAE Systems, Raytheon #include "ALMAS_Client.idl" #include "ALMAS_DataModel.idl" #ifndef __ALMAS_Management_DEF #define __ALMAS_Management_DEF #pragma prefix "omg.org" module ALMAS_Management { typedef sequence<ALMAS_DataModel::ALMAS_Alert> ALMAS_AlertSet; typedef sequence<ALMAS_DataModel::ALMAS_TemplateIDType> ALMAS_TemplateIDTypeSet; interface ALMAS_Manager { attribute string ALMAS_SystemID; // alert retrieval methods ALMAS_DataModel::ALMAS_CallStatus GetAlert ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, out ALMAS_DataModel::ALMAS_Alert Alert); ALMAS_DataModel::ALMAS_CallStatus GetAlerts ( in string Filter, out ALMAS_AlertSet AlertSet); // ALMAS-wide control methods ALMAS_DataModel::ALMAS_CallStatus SetAlertInhibited ( in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID, in boolean Inhibition); ALMAS_DataModel::ALMAS_CallStatus UpdateDynamicMessageData ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in string ObjectValue, in ALMAS_DataModel::ALMAS_DynamicMessageDataType OldValue); ALMAS_DataModel::ALMAS_CallStatus RegisterNotificationListener ( in ALMAS_Client::ALMAS_NotificationListener Handle); // Template management methods ALMAS_DataModel::ALMAS_CallStatus GetTemplate ( in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID, out ALMAS_DataModel::ALMAS_AlertTemplateType Template); ALMAS_DataModel::ALMAS_CallStatus GetAllTemplateIDs ( in string Filter, out ALMAS_TemplateIDTypeSet TemplateIDSet); }; interface ALMAS_ManagerExtensions : ALMAS_Manager { ALMAS_DataModel::ALMAS_CallStatus RemoveAlertsWithDynamicData ( in string CancellerID, in string DataType, in string DataValue); ALMAS_DataModel::ALMAS_CallStatus AttachCategorisationRule ( in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID, in long RuleID); ALMAS_DataModel::ALMAS_CallStatus DetachCategorisationRule ( in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID, in long RuleID); }; interface ALMAS_Producer { ALMAS_DataModel::ALMAS_CallStatus RaiseAlertFromOverrides ( in string ProducerID, in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID, in ALMAS_DataModel::ALMAS_CategoryType Category, in boolean ValidCategory, in short Priority, in boolean ValidPriority, in ALMAS_DataModel::ALMAS_StatusType Status, in boolean ValidStatus, in ALMAS_DataModel::ALMAS_ScopeType Scope, in boolean ValidScope, in ALMAS_DataModel::ALMAS_TimeoutType Timeout, in boolean ValidTimeout, in boolean ConfirmationRequired, in boolean ValidConfirmationRequired, in string SecondaryGrouping, in boolean ValidSecondaryGrouping, in boolean Persistent, in boolean ValidPersistent, in boolean ReliablyDistributed, in boolean ValidReliablyDistributed, in ALMAS_DataModel::ALMAS_TimeoutActionType TimeoutAction, in boolean ValidTimeoutAction, in ALMAS_DataModel::ALMAS_AckModelType AcknowledgementModel, in boolean ValidAcknowledgementModel, in ALMAS_DataModel::ALMAS_StaticMessageSet StaticMessages, in boolean ValidStaticMessages, in ALMAS_DataModel::ALMAS_DynamicMessageDataTypeSet DynamicMessageData, in boolean ValidDynamicMessageData, in ALMAS_DataModel::ALMAS_ReceiverKindTypeSet AlertReceivers, in boolean ValidAlertReceiverSet, out ALMAS_DataModel::ALMAS_AlertIDType AlertID); ALMAS_DataModel::ALMAS_CallStatus RaiseAlertFromData ( in string ProducerID, in ALMAS_DataModel::ALMAS_AlertTemplateType AlertInfo, out ALMAS_DataModel::ALMAS_AlertIDType AlertID); ALMAS_DataModel::ALMAS_CallStatus RaiseAlertFromTemplate ( in string ProducerID, in ALMAS_DataModel::ALMAS_TemplateIDType TemplateID, out ALMAS_DataModel::ALMAS_AlertIDType AlertID); ALMAS_DataModel::ALMAS_CallStatus UpdateAlertPriority ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in string ProducerID, in short Priority); ALMAS_DataModel::ALMAS_CallStatus CancelAlert ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in string CancellerID, in string CancellationReason); }; interface ALMAS_Responder { ALMAS_DataModel::ALMAS_CallStatus RegisterReceiver ( in ALMAS_Client::ALMAS_Receiver ReceiverHandle, in string ReceiverID, in string RKType); ALMAS_DataModel::ALMAS_CallStatus UnregisterReceiver ( in string ReceiverID); ALMAS_DataModel::ALMAS_CallStatus AcknowledgeAlert ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in string ReceiverID); ALMAS_DataModel::ALMAS_CallStatus HandleAlert ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in string ReceiverID); ALMAS_DataModel::ALMAS_CallStatus ConfirmReceipt ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, in string ReceiverID); }; interface ALMAS_ResponderExtensions : ALMAS_Responder { ALMAS_DataModel::ALMAS_CallStatus SetLanguage ( in string ReceiverID, in string Language); ALMAS_DataModel::ALMAS_CallStatus GetFilledMessageText ( in ALMAS_DataModel::ALMAS_AlertIDType AlertID, out string MessageText); }; interface ALMAS_Configuration { ALMAS_DataModel::ALMAS_CallStatus LoadReceiverHierarchy ( in string Filename ); ALMAS_DataModel::ALMAS_CallStatus LoadTemplateSet ( in string Filename ); ALMAS_DataModel::ALMAS_CallStatus LoadConfiguration ( in string Filename ); }; }; #endif Updated IDL for section 10.4 as in issue 12988:
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 12992: Section 2.6.1.1 ALMAS_DataModel.idl (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Added prefix "ALMAS_" to enums to avoid conflict with existing definitions within our system.
Resolution: This is only necessary for the DCOM mapping and affects IDL in section 10.2 only
Revised Text: See updated IDL for 10.2 in issue 12988
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 12993: Sections 2.6.1.3, 2.7.4.2, 2.8.1.3 (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: Sections 2.6.1.3, 2.7.4.2, 2.8.1.3 Query - Method UpdateDynamicMessage takes in OldValue - why?
Resolution: No change to model Add the following to UpdateDynamicMessageData description in 6.3.3: "OldData is necessary in order to clearly indicate which dynamic message data should be changed."
Revised Text: The changes to section 6.3.3 are covered by issue 12290.
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 12994: 2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: 2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs - cannot return data directly. Will need to be returned from additional callbacks on the appropirate interfaces, so out parameter now removed and replaced with an input parameter to pass in the receiver's handle.
Resolution: This affect the DCOM interface for ALMAS Notification Listener in section 10.3
Revised Text: See updated IDL for section 10.3 in issue 12988
Actions taken:
October 28, 2008: received issue
July 23, 2009: closed issue
Issue 13013: ALMAS configuration files contain not valid xsd constructs (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: ALMAS configuration files contain not valid xsd constructs. E.g. Alert_Definitions.xsd/24-01-2008: xs:restriction not terminated. ALMAS_Categorisation.xsd/23-01-2008: space chars invalid in some attributes. ALMAS_Hierarchy.xsd/24-01-2008: invalid characters (--) in element. Solution: Validate configuration files with appropriate xml editor.
Resolution: XSD files validated.
Revised Text: Revised XSD for section 7.1 as below: <?xml version="1.0" encoding="UTF-8"?> <!-- Alert Data Template schema --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0a" id="Alert_Template_Data"> <xs:element name="Alert_Template_Root" type="Alerts_Templates_T"> <xs:annotation> <xs:documentation>Root element containing Alert Template Data.</xs:documentation> </xs:annotation> <xs:unique name="Template_Id"> <xs:selector xpath="./Alert_Template"/> <xs:field xpath="Template_Id"/> </xs:unique> </xs:element> <xs:complexType name="Alerts_Templates_T"> <xs:sequence> <xs:element name="Alert_Template" type="Alerts_Template_T" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>The template of an alert.</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="Alerts_Template_T"> <xs:sequence> <xs:element name="Template_Id"> <xs:simpleType> <xs:annotation> <xs:documentation>The unique template identifier.</xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Alert_Category"> <xs:simpleType> <xs:annotation> <xs:documentation>Enumeration of Alert Category.</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="Action"/> <xs:enumeration value="Situation"/> <xs:enumeration value="Information"/> <xs:enumeration value="Warning"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Alert_Default_Priority"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxInclusive value="99"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Status"> <xs:simpleType> <xs:annotation> <xs:documentation>OASIS CAP Derived Status</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="Actual"/> <xs:enumeration value="Exercise"/> <xs:enumeration value="System"/> <xs:enumeration value="Test"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Scope"> <xs:simpleType> <xs:annotation> <xs:documentation>OASIS CAP Derived Scope</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="PublicScope"/> <xs:enumeration value="RestrictedScope"/> <xs:enumeration value="PrivateScope"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Timeout"> <xs:simpleType> <xs:annotation> <xs:documentation>Time until alert timeout in seconds, where 0 indicates no timeout required</xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="3600"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="ConfirmationRequired" type="xs:boolean"/> <xs:element name="Secondary_Grouping" minOccurs="0"> <xs:simpleType> <xs:annotation> <xs:documentation>Secondary grouping for filtering aid</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:element> <xs:element name="Persistent" type="xs:boolean"/> <xs:element name="ReliablyDistributed" type="xs:boolean"/> <xs:element name="TimeoutAction"> <xs:simpleType> <xs:annotation> <xs:documentation>The action to be performed upon alert timeout</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="CancelOnly"/> <xs:enumeration value="NotifyOnly"/> <xs:enumeration value="CancelWithNotify"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="AcknowledgementModel"> <xs:simpleType> <xs:annotation> <xs:documentation>Required acknowledgement profile before progressing the alert to 'Acknowledged'</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="AckByNone"/> <xs:enumeration value="AckByAnyone"/> <xs:enumeration value="AckByAll"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Inhibited" type="xs:boolean" minOccurs="0"/> <xs:element name="Raise_To_All" type="xs:boolean"/> <xs:element name="Static_Message" type="Static_Message_T" maxOccurs="unbounded"/> <xs:element name="Alert_Data_Extra_Attributes" type="Alert_Data_Extra_Attributes_T" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Dynamic_Message_Data" type="Dynamic_Message_Data_T" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Alert_Routing" type="Alert_Routing_T" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="Static_Message_T"> <xs:sequence> <xs:element name="MessageText"> <xs:simpleType> <xs:annotation> <xs:documentation>The Alert Template Text</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="MessageLanguage"> <xs:simpleType> <xs:annotation> <xs:documentation>The alert locale</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="Alert_Data_Extra_Attributes_T"> <xs:sequence> <xs:element name="Name"> <xs:simpleType> <xs:annotation> <xs:documentation>The Attribute Name</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="TypeOfByteData"> <xs:simpleType> <xs:annotation> <xs:documentation>Flag to indicate the type of data</xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Description"> <xs:simpleType> <xs:annotation> <xs:documentation>Description of contents e.g. image(jpg), URL, Track report etc</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="Dynamic_Message_Data_T"> <xs:sequence> <xs:element name="Variable_Type"> <xs:simpleType> <xs:annotation> <xs:documentation>Type of variable data</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Tag"> <xs:annotation> <xs:documentation>The position of the data item within message</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxInclusive value="20"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="Alert_Routing_T"> <xs:sequence> <xs:element name="Receiver_Kind"> <xs:annotation> <xs:documentation>A receiver kind</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="AlternativeAction" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>A none standard alert response</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Actionee_Priority"> <xs:annotation> <xs:documentation>The priority of the actionee to deal with this alert</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxInclusive value="10"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema> Revised XSD for section 7.2 as below: <?xml version="1.0" encoding="UTF-8" ?> <!-- ALMAS Configuration --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0a" id="ALMAS_Configuration_Data"> <xs:element name="ALMAS_Config_Root" type="Alerts_Config_T"> <xs:annotation> <xs:documentation>Root element containing ALMAS Configuration Data.</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="Alerts_Config_T"> <xs:sequence> <xs:element name="Max_No_Alerts"> <xs:annotation> <xs:documentation>Maximum number of alerts in the system</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Max_No_Alerts_For_Receiver"> <xs:annotation> <xs:documentation>Maximum number of alerts for each receiver</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema> Revised XSD for section 7.3 as below: <?xml version="1.0" encoding="UTF-8" ?> <!-- Receiver Hierarchy schema --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0a" id="Receiver_Hierarchy_Data"> <xs:element name="Receiver_Hierarchy_Root" type="Receiver_Hierarchy_T"> <xs:annotation> <xs:documentation>Root element containing Hierarchy Data.</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="Receiver_Hierarchy_T"> <xs:sequence> <xs:element name="Receiver_Kind" type="Receiver_Kind_T" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>A Receiver Kind</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="Receiver_Kind_T"> <xs:sequence> <xs:element name="Type"> <xs:annotation> <xs:documentation>The receiver kind e.g. SPS</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1" /> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="ParentType"> <xs:annotation> <xs:documentation>The 'type' of the receiver kind's parent e.g. TPS</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1" /> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema> Revised XSD for section 7.4 as below: <?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Categorisation_Rule_Set" type="Categorisation_Rule_Set"/> <xs:complexType name="Categorisation_Rule_Set"> <xs:sequence> <xs:element name="Alert_Categorisation_Rule" type="Alert_Categorisation_Rule"/> </xs:sequence> </xs:complexType> <xs:element name="Alert_Categorisation_Rule" type="Alert_Categorisation_Rule"/> <xs:complexType name="Alert_Categorisation_Rule"> <xs:sequence> <xs:element name="ruleID" type="xs:int"/> <xs:element name="action" type="Categorisation_Action" maxOccurs="unbounded"/> <xs:element name="condition" type="Categorisation_Condition"/> <xs:element name="trigger" type="Categorisation_Trigger"/> </xs:sequence> </xs:complexType> <xs:element name="Categorisation_Trigger" type="Categorisation_Trigger"/> <xs:complexType name="Categorisation_Trigger"> <xs:sequence> <xs:element name="terms" type="Event" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="RelativeEvent" type="RelativeEvent"/> <xs:complexType name="RelativeEvent"> <xs:complexContent> <xs:extension base="TimeEvent"> <xs:sequence> <xs:element name="interval" type="xs:double"/> <xs:element name="reference_event" type="Event"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="PeriodicEvent" type="PeriodicEvent"/> <xs:complexType name="PeriodicEvent"> <xs:complexContent> <xs:extension base="TimeEvent"> <xs:sequence> <xs:element name="interval" type="xs:double"/> <xs:element name="start_event" type="Event"/> <xs:element name="end_event" type="Event"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="AbsoluteEvent" type="AbsoluteEvent"/> <xs:complexType name="AbsoluteEvent"> <xs:complexContent> <xs:extension base="TimeEvent"> <xs:sequence> <xs:element name="time_moment" type="xs:date"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="Categorisation_Action" type="Categorisation_Action"/> <xs:complexType name="Categorisation_Action"> <xs:sequence/> </xs:complexType> <xs:element name="Categorisation_Condition" type="Categorisation_Condition"/> <xs:complexType name="Categorisation_Condition"> <xs:sequence> <xs:element name="condition_formula" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="Raise_Action" type="Raise_Action"/> <xs:complexType name="Raise_Action"> <xs:complexContent> <xs:extension base="Categorisation_Action"> <xs:sequence> <xs:element name="raised_alert" type="Alert"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="Alert" type="Alert"/> <xs:complexType name="Alert"> <xs:sequence/> </xs:complexType> <xs:element name="Event" type="Event"/> <xs:complexType name="Event"> <xs:sequence/> </xs:complexType> <xs:element name="TimeEvent" type="TimeEvent"/> <xs:complexType name="TimeEvent"> <xs:complexContent> <xs:extension base="Event"> <xs:sequence/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="Operator_Event" type="Operator_Event"/> <xs:complexType name="Operator_Event"> <xs:complexContent> <xs:extension base="Event"> <xs:sequence> <xs:element name="action" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="Change_Event" type="Change_Event"/> <xs:complexType name="Change_Event"> <xs:complexContent> <xs:extension base="Event"> <xs:sequence> <xs:element name="change" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>
Actions taken:
October 30, 2008: received issue
July 23, 2009: closed issue
Issue 13014: Method GetAllTemplateIDs of ALMASManager not mapped (almas-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: Method GetAllTemplateIDs of ALMASManager not mapped. Solution: Map to: DDS read with query condition.
Resolution: Add to table on page 59 one row below method GetTemplate: "ALMAS Manager - GetAllTemplateIDs (String, TemplateIDSet) - DDS read with query condition"
Revised Text: Add to table in 9.3.2 one row below method GetTemplate: "ALMAS Manager - GetAllTemplateIDs (String, TemplateIDSet) - DDS read with query condition"
Actions taken:
October 30, 2008: received issue
July 23, 2009: closed issue
Issue 13015: Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides) (almas-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Critical
Summary: By means of RaiseAlertFromData an alert can be raised that is not present in the ALMAS template database. However, receivers (ReceiverKind, see Section 6.2) can only be associated with templates. How can receivers now be defined? Solution: Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides)?
Resolution: To reduce the complexity of this the approach taken is to change the AlertData parameter type to be an AlertTemplate parameter - this is not read or initialised from the XML, so the TemplateID field is invalid, but it reduces the complexity of the interface significantly.
Revised Text: The changes for Section 6.3 figure and 6.3.5 have been carried out as part of issue 12290 changes. See IDL updates for 8.4 in issue 12991 See IDL updates for 10.4 in issue 12988 IDL for section 9.3.2 replace with the following: // copyright 2005-8 THALES, BAE Systems, Raytheon #include "ALMAS_DataModel.idl" #ifndef __ALMAS_Management_DEF #define __ALMAS_Management_DEF module ALMAS_Management { typedef sequence<ALMAS_DataModel::ALMAS_Alert> ALMAS_AlertSet; struct ALMAS_Response { long long request_id; ALMAS_DataModel::ALMAS_CallStatus error_code; }; #pragma keylist ALMAS_Response request_id // Need a singleton topic for ALMAS_Manager since it has attributes struct ALMAS_Manager { string SystemID;}; #pragma keylist ALMAS_Manager struct ALMAS_RaiseAlertFromTemplate { long long request_id; string ProducerID; ALMAS_DataModel::ALMAS_TemplateIDType TemplateID; }; #pragma keylist ALMAS_RaiseAlertFromTemplate request_id struct ALMAS_RegisterReceiver { long long request_id; string ReceiverID; string RKType; }; #pragma keylist ALMAS_RegisterReceiver request_id struct ALMAS_UnregisterReceiver { long long request_id; string ReceiverID; }; #pragma keylist ALMAS_UnregisterReceiver request_id struct ALMAS_RaiseAlertFromOverrides { long request_id; string ProducerID; ALMAS_DataModel::ALMAS_TemplateIDType TemplateID; ALMAS_DataModel::ALMAS_AlertDataAttributesType Attributes; boolean CategoryValid; boolean PriorityValid; boolean StatusValid; boolean ScopeValid; boolean TimeoutValid; boolean ConfirmationRequiredValid; boolean SecondaryGroupingValid; boolean PersistentValid; boolean ReliablyDistributedValid; boolean TimeoutActionValid; boolean AcknowledgementModelValid; boolean StaticMessagesValid; boolean DynamicMessagesValid; }; #pragma keylist ALMAS_RaiseAlertFromOverrides request_id struct ALMAS_RaiseAlertFromData { long long request_id; string ProducerID; ALMAS_DataModel::ALMAS_AlertTemplateType AlertInfo; }; #pragma keylist ALMAS_RaiseAlertFromData request_id struct ALMAS_CreatedAlert { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; }; #pragma keylist ALMAS_CreatedAlert request_id struct ALMAS_UpdateAlertPriority { long long request_id; string ProducerID; ALMAS_DataModel::ALMAS_AlertIDType AlertID; short Priority; }; #pragma keylist ALMAS_UpdateAlertPriority request_id struct ALMAS_CancelAlert { long long request_id; string CancellerID; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string CancellationReason; }; #pragma keylist ALMAS_CancelAlert request_id struct ALMAS_AcknowledgeAlert { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string ReceiverID;}; #pragma keylist ALMAS_AcknowledgeAlert request_id struct ALMAS_HandleAlert { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string ReceiverID;}; #pragma keylist ALMAS_HandleAlert request_id struct ALMAS_ConfirmReceipt { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string ReceiverID;}; #pragma keylist ALMAS_ConfirmReceipt request_id struct ALMAS_SetLanguage { long long request_id; string ReceiverID; string Language;}; #pragma keylist ALMAS_SetLanguage request_id struct ALMAS_GetFilledMessageText { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string ReceiverID;}; #pragma keylist ALMAS_GetFilledMessageText request_id struct ALMAS_FilledMessageText { long long request_id; ALMAS_DataModel::ALMAS_StringSet Messages; }; #pragma keylist ALMAS_FilledMessageText request_id struct ALMAS_LoadReceiverHierarchy { long long request_id; string Filename ;}; #pragma keylist ALMAS_LoadReceiverHierarchy request_id struct ALMAS_LoadTemplateSet { long long request_id; string Filename; }; #pragma keylist ALMAS_LoadTemplateSet request_id struct ALMAS_LoadConfiguration { long long request_id; string Filename; }; #pragma keylist ALMAS_LoadConfiguration request_id struct ALMAS_UpdateDynamicMessageData { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string DataValue; ALMAS_DataModel::ALMAS_DynamicMessageDataType OldData; }; #pragma keylist ALMAS_UpdateDynamicMessageData request_id struct ALMAS_SetAlertInhibited { long long request_id; ALMAS_DataModel::ALMAS_TemplateIDType TemplateID; boolean Inhibition; }; #pragma keylist ALMAS_SetAlertInhibited request_id struct ALMAS_AttachCategorisationRule { long long request_id; long RuleID; ALMAS_DataModel::ALMAS_TemplateIDType TemplateID; }; #pragma keylist ALMAS_AttachCategorisationRule request_id struct ALMAS_DetachCategorisationRule { long long request_id; long RuleID; ALMAS_DataModel::ALMAS_TemplateIDType TemplateID; }; #pragma keylist ALMAS_DetachCategorisationRule request_id struct ALMAS_RemoveAlertsWithDynamicMessageData { long long request_id; string CancellerID; string DataType; string DataValue; }; #pragma keylist ALMAS_RemoveAlertsWithDynamicMessageData request_id }; #endif
Actions taken:
Issue 13016: priority attribute value (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Is the priority attribute value independent of the category meaning that an information alert can have a higher priority than a situation alert?
Resolution: Add to 6.2.2 description for Priority "the priority is open for client use and not intended for interpretation by ALMAS."
Revised Text: Change made as part of updates for issue 12290
Actions taken:
October 30, 2008: received issue
October 30, 2008: received issue
July 23, 2009: closed issue
Issue 13017: Attribute TimeoutAction (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Attribute TimeoutAction: There seems to be no way to inform somebody about a timeout. Solution: Enable notification by ALMASReceiver.stateChangeNotification(int, Enumeration) and adding Timed_Out to the enumeration.
Resolution: Change 6.2.1 description for CurrentState to include "Timed_Out" after "Cancelled"
Revised Text: Changes to 6.2.1 carried out as part of issue 12290. IDL changes for section 8.2 are as follows: // Copyright 2005-2008 THALES, BAE Systems, Raytheon #include "timebase.idl" #ifndef __ALMAS_DataModel_DEF #define __ALMAS_DataModel_DEF #pragma prefix "omg.org" module ALMAS_DataModel { typedef long ALMAS_AlertIDType; typedef long ALMAS_TemplateIDType; typedef long ALMAS_TimeoutType; typedef TimeBase::TimeT ALMAS_DateTimeType; // EVoT compatible long long typedef sequence<octet> ALMAS_ByteSequence; typedef sequence<string> ALMAS_StringSet; enum ALMAS_CategoryType { Action, Warning, Information, Situation}; enum ALMAS_StateType { Raised, Routed, Received, Acknowledged, Handled, Cancelled, TimedOut}; enum ALMAS_StatusType { Actual, Exercise, System, Test}; enum ALMAS_ScopeType { PublicScope, RestrictedScope, PrivateScope}; enum ALMAS_TimeoutActionType { CancelOnly, NotifyOnly, CancelWithNotify}; enum ALMAS_AckModelType { AckByNone, AckByAnyone, AckByAll}; struct ALMAS_CallStatus { boolean Success; short Reason; string Description; }; struct ALMAS_ValidAlertResponseType { ALMAS_StringSet AlternativeAction; short ActioneePriority; }; struct ALMAS_ReceiverKindType { string RKType; string RKParentType; ALMAS_ValidAlertResponseType ValidResponse; }; typedef sequence<ALMAS_ReceiverKindType> ALMAS_ReceiverKindTypeSet; struct ALMAS_DynamicMessageDataType { string DataType; string DataTag; string DataValue; }; typedef sequence<ALMAS_DynamicMessageDataType> ALMAS_DynamicMessageDataTypeSet; struct ALMAS_StaticMessageType { string MessageText; string MessageLanguage; }; typedef sequence<ALMAS_StaticMessageType> ALMAS_StaticMessageTypeSet; struct ALMAS_AlertDataExtraAttributesType { string Name; short TypeOfByteData; string Description; ALMAS_ByteSequence Value; }; typedef sequence<ALMAS_AlertDataExtraAttributesType> ALMAS_AlertDataExtraAttributesTypeSet; struct ALMAS_AlertDataType { ALMAS_TemplateIDType TemplateID; ALMAS_CategoryType Category; short Priority; ALMAS_StatusType Status; ALMAS_ScopeType Scope; ALMAS_TimeoutType Timeout; boolean ConfirmationRequired; string SecondaryGrouping; boolean Persistent; boolean ReliablyDistributed; ALMAS_TimeoutActionType TimeoutAction; ALMAS_AckModelType AcknowledgementModel; ALMAS_StaticMessageTypeSet StaticMessages; ALMAS_DynamicMessageDataTypeSet DynamicMessages; ALMAS_AlertDataExtraAttributesTypeSet ExtraAttributes; }; struct ALMAS_AlertTemplateType { boolean Inhibited; boolean RaiseToAll; ALMAS_AlertDataType AlertData; ALMAS_ReceiverKindTypeSet ReceiverKinds; }; struct ALMAS_AlertReportType { boolean Acknowledged; boolean Routed; boolean Actioned; boolean ReceiverIsActionee; ALMAS_StringSet AlternativeAction; string ReceiverID; ALMAS_AlertIDType AlertID; }; struct ALMAS_AvailableAlertReceiverType { string ReceiverID; ALMAS_ReceiverKindType ReceiverKind; }; typedef sequence<ALMAS_AvailableAlertReceiverType> ALMAS_AvailableAlertReceiverTypeSet; struct ALMAS_Alert { ALMAS_AlertIDType AlertID; ALMAS_DateTimeType RaisingTime; ALMAS_StateType CurrentState; string ProducerID; ALMAS_AlertDataType AlertData; ALMAS_AvailableAlertReceiverTypeSet Receivers; }; }; #endif IDL changes for section 9.2 are as follows: // copyright 2005-8 THALES, BAE Systems, Raytheon // #include "timebase.idl" #include "dds_dcps.idl" // use for DDS standard compatible time types #ifndef __ALMAS_DataModel_DEF #define __ALMAS_DataModel_DEF module ALMAS_DataModel { typedef long long ALMAS_AlertIDType; typedef long ALMAS_TemplateIDType; typedef long ALMAS_TimeoutType; // typedef TimeBase::TimeT ALMAS_DateTimeType; // EVoT compatible - long long typedef DDS::Time_t ALMAS_DateTimeType; // DDS compatible typedef sequence<octet> ALMAS_ByteSequence; typedef sequence<string> ALMAS_StringSet; enum ALMAS_CategoryType { Action, Warning, Information, Situation}; enum ALMAS_StateType { Raised, Routed, Received, Acknowledged, Handled, Cancelled Timed_Out}; enum ALMAS_StatusType { Actual, Exercise, System, Test}; enum ALMAS_ScopeType { PublicScope, RestrictedScope, PrivateScope}; enum ALMAS_TimeoutActionType { CancelOnly, NotifyOnly, CancelWithNotify}; enum ALMAS_AckModelType { AckByNone, AckByAnyone, AckByAll}; struct ALMAS_CallStatus { boolean Success; short Reason; string Description; }; struct ALMAS_ValidAlertResponseType { ALMAS_StringSet AlternativeAction; short ActioneePriority; }; struct ALMAS_ReceiverKindType { string RKType; string RKParentType; ALMAS_ValidAlertResponseType ValidResponse; }; typedef sequence<ALMAS_ReceiverKindType> ALMAS_ReceiverKindTypeSet; struct ALMAS_DynamicMessageDataType { string DataType; string DataTag; string DataValue; }; typedef sequence<ALMAS_DynamicMessageDataType> ALMAS_DynamicMessageDataTypeSet; struct ALMAS_StaticMessageType { string MessageText; string MessageLanguage; }; typedef sequence<ALMAS_StaticMessageType> ALMAS_StaticMessageTypeSet; struct ALMAS_AlertDataAttributesType { ALMAS_CategoryType Category; short Priority; ALMAS_StatusType Status; ALMAS_ScopeType Scope; ALMAS_TimeoutType Timeout; boolean ConfirmationRequired; string SecondaryGrouping; boolean Persistent; boolean ReliablyDistributed; ALMAS_TimeoutActionType TimeoutAction; ALMAS_AckModelType AcknowledgementModel; ALMAS_StaticMessageTypeSet StaticMessages; ALMAS_DynamicMessageDataTypeSet DynamicMessages; }; struct ALMAS_AlertDataExtraAttributesType { string Name; short TypeOfByteData; string Description; ALMAS_ByteSequence Value; }; typedef sequence<ALMAS_AlertDataExtraAttributesType> ALMAS_AlertDataExtraAttributesTypeSet; struct ALMAS_AlertDataType { ALMAS_TemplateIDType TemplateID; ALMAS_AlertDataAttributesType Attributes; ALMAS_AlertDataExtraAttributesTypeSet ExtraAttributes; }; struct ALMAS_AlertTemplateType { boolean Inhibited; boolean RaiseToAll; ALMAS_AlertDataType AlertData; ALMAS_ReceiverKindTypeSet ReceiverKinds; }; #pragma keylist ALMAS_AlertTemplateType AlertData.TemplateID struct ALMAS_AlertReportType { boolean Acknowledged; boolean Routed; boolean Actioned; boolean ReceiverIsActionee; ALMAS_StringSet AlternativeAction; string ReceiverID; ALMAS_AlertIDType AlertID; }; #pragma keylist ALMAS_AlertReportType ReceiverID, AlertID struct ALMAS_AvailableAlertReceiverType { string ReceiverID; ALMAS_ReceiverKindType ReceiverKind; }; typedef sequence<ALMAS_AvailableAlertReceiverType> ALMAS_AvailableAlertReceiverTypeSet; struct ALMAS_Alert { ALMAS_AlertIDType AlertID; ALMAS_DateTimeType RaisingTime; ALMAS_StateType CurrentState; string ProducerID; ALMAS_AlertDataType AlertData; ALMAS_AvailableAlertReceiverTypeSet Receivers; }; #pragma keylist ALMAS_Alert AlertID }; #endif See issue 12988 for changes to 10.2
Actions taken:
October 30, 2008: received issue
July 23, 2009: closed issue
Issue 13018: ALMASReceiver.stateChangeNotification(int, Enumeration) (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: ALMASReceiver.stateChangeNotification(int, Enumeration): The values of the Enumeration are not specified. Solution: Same enumerations as for Alert.CurrentState.
Resolution: Add to 6.1.2 the following "These states are the same states as used in CurrentState for an Alert."
Revised Text: Changes to 6.1.2 carried out as part of issue 12290.
Actions taken:
October 30, 2008: received issue
July 23, 2009: closed issue
Issue 13019: Catgorisation rules (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary: Catgorisation rules must be defined offline by means of the "ALMAS categorisation rule file". Rules can be attached and detached to alerts by means of methods "AttachCategorisationRule" and "DetachCategorisationRule". An alert can only be attached after it exists, so after it is raised. However, the intention of categorisation is to do an action (e.g. raising an alert) according to a condition on occurence of an event. There seems to be a chicken-and-egg problem. Solution: Attach/detach AlertTemplate instead of Alert?
Resolution: Update figure 6.3 and section 6.3.4 - Use TemplateID instead of AlertID as parameter for both Attach� and Detach� methods. Change alert to AlertTemplate in both descriptions. Update IDL for these methods.
Revised Text: Changes to figure 6.3 and 6.3.4 carried out as part of issue 12290. IDL changes for section 8.4 are captured in issue 12991 IDL changes for section 9.3.2 are captured in issue 13015 IDL changes for section 9.4.2 are captured in issue 13015 IDL changes for section 10.4 are captured in issue 12988
Actions taken:
October 30, 2008: received issue
July 23, 2009: closed issue
Issue 13020: DynamicMessageData instances (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: The number of DynamicMessageData instances is fixed for an Alert(Template). This means that for a specific Alert only a fixed maximum number of tags can be used. When you want to raise an alert like "Tracks present in an area", this number should be dynamic.
Resolution: Remove the number limitations of items Static_message, Alert_Data_extra_Attributes, Dynamic_Message_Data, Alert_Routing from the Alert_definitions.xsd file and item Receiver_Kind from the ALMAS_Hierarchy.xsd configuration file. Note that also fixed string lengths as defined in the configuration files are unnecessarily restrictive and should be removed.
Revised Text: XSD changes for section 7.1 are captured in issue 13013 XSD changes for section 7.3 are captured in issue 13013
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13021: RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert). (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert). ALMAS must know which ReceiverKinds are active in the system at a certain moment. For example which roles are played that are interested in alerts. A (future) Role management system will not export such a relation because it will not import ALMAS particulars. Worse, it is not even able to do so because in OpenSplice it is not possible to determine which listeners are present for a certain topic. Even when that would be possible, there is no way to relate listeners to e.g. roles. Solution: For registration declare a new topic containing a RKType?
Resolution: Remove ALMAS Responder - RegisterReceiver from table in section 9.3.2.
Revised Text: IDL changes for section 9.3.2 are captured in issue 13015
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Discussion:
Issue 13022: mapping a number of methods (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary: It would be better to map a number of methods, which are now directly mapped on DDS level constructs, on control topics because of two reasons: 1. Without control topics a producer can not be directly notified of a producer or system related error/problem. E.g. when a producer produces a new alert, he can not be notified that this was not succesfull because no active receivers are present. 2. Much more important: An alert contains ""static"" information but also state information (e.g. AlertId, Currentstate, Receivers etc.). Only ALMAS should be allowed to maintain this information, not a producer. Because a producer can now write a complete Alert, it may also write state information. This would violate data hiding principles and therefore ALMAS would be unnecessarely complex and obscure. Solution: The following methods should map on control topics: 1. UpdateDynamicMessageData 2. SetAlertInhibited 3. RemoveAlertsWithDynamicMessageData 4. RaiseAlertFromOverrides 5. RaiseAlertFromData 6. UpdateAlert
Resolution: Remove the following items from table in section 9.3.2: ALMAS Manager - UpdateDynamicMessageData ALMAS Manager - SetAlertInhibited ALMAS Manager - RemoveAlertsWithDynamicMessageData ALMAS Producer - RaiseAlertFromOverrides ALMAS Producer - RaiseAlertFromData ALMAS Producer - CancelAlert Add the following new topics ALMAS_UpdateDynamicMessageData, ALMAS_SetAlertInhibited, ALMAS_RemoveAlertsWithDynamicMessageData , ALMAS_RaiseAlertFromOverrides, ALMAS_RaiseAlertFromData, ALMAS_CancelAlert to DCPS IDL For the purpose of these new topics, note that attributes are removed from struct ALMAS_AlertDataType and now contained in new struct ALMAS_AlertDataAttributesType.
Revised Text: IDL changes for section 9.3.2 are captured in issue 13015
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13024: Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01 (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01
Resolution: Copy correct picture and update figure 6.6 to same style.
Revised Text: nsert this figure in place of current figure 6.5 Insert this figure in place of current figure 6.6 Disposition: Resolved
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13025: Removal of alerts is not clearly addressed in the spec (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary: Removal of alerts is not clearly addressed in the spec. Should be addressed explicitly. Solution: Alerts are removed as follows: . For all alert categories holds that they are removed when cancelled by the producer. . Information and Warning alerts: Removed when an acknowledge is required and the appropriate acknowledge is given or when a timeout is defined when the timeout is expired or when no timeout is defined a general (adaptable) timeout is assumed. . Action alert: Removed when HandleAlert is called by all addressees. . Situation alert: Will not be removed when HandleAlert is called by all addressees. Will only be removed if cancelled by producer.
Resolution: Covered as part of issue 12290 response. For clarity the updates to section 6.3 are repeated here: � For all alert categories, an alert is removed when cancelled. Note that Situation alerts are only removed when cancelled. � Information and Warning alerts are removed when the required number of acknowledgements (as identified in the AlertData AcknowledgementModel attribute) are given or (if a timeout is defined) when the timeout is expired. � Action alerts are removed when HandleAlert is called by the Receiver identified as the Actionee in its AlertReport.
Revised Text: Covered as part of issue 12290 response.
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13026: UpdateAlert not useful, so remove it from the spec (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary: UpdateAlert:By means of an UpdateAlert a producer can update an already raised alert with new AlertData as parameter. Two problems here: 1. The producer may change all attributes of the AlertData making this very complex to realise. However, most, if not all attributes, are not likely te be changed. 2. The alert may already be partly (by some addresses) handled making the realisation even more complex. Solution: UpdateAlert not useful, so remove it from the spec.
Resolution: Reduce the scope of UpdateAlert to cover the change of priority and rename to be UpdateAlertPriority. Update figure 6.3, section 6.3.5 and the management IDL files
Revised Text: Section 6.3.5 and figure 6.3 are covered by issue 12290. IDL changes for section 8.4 are captured in issue 12991 IDL changes for section 9.3.2 are captured in issue 13015 IDL changes for section 9.4.2 are captured in issue 13015 IDL changes for section 10.4 are captured in issue 12988
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13027: Consistently start methods with capitals (or not). (almas-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary: Consistently start methods with capitals (or not).
Resolution: Figure 6.1: stateChangeNotification => StateChangeNotification alertDataNotification => AlertDataNotification alertDistributionNotification => AlertDistributionNotification 6.1.2: stateChangeNotification => StateChangeNotification alertDataNotification => AlertDataNotification
Revised Text: Changes as above made as part of issue 12290
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13028: Operation Unregister should be UnregisterReceiver (almas-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary: Operation Unregister should be UnregisterReceiver
Resolution: 6.3.6 Replace operation Unregister by UnregisterReceiver. Also update the IDL in 8.4, 9.3.2, 9.4.2, 10.4
Revised Text: Section 6.3.6 changes made as part of issue 12290. IDL changes for section 8.4 are captured in issue 12991 IDL changes for section 9.3.2 are captured in issue 13015 IDL changes for section 9.4.2 are captured in issue 13015 IDL changes for section 10.4 are captured in issue 12988
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13029: Enable receiver hierarchy per alert template? (almas-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: Hierarchy, as can be specified according the Receiver Hierarchy Configuration file is alert (Template) independent. Is this not too restrictive? Solution: Enable receiver hierarchy per alert template?
Resolution:
Revised Text:
Actions taken:
October 31, 2008: received issue
April 30, 2009: Deferred
July 23, 2009: closed issue
Discussion: A consistent hierarchy for all alerts was intended originally. It is not clear how much use will be made of this feature so resolution is deferred until a revision task force.
Issue 13030: Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType? (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType? RKParentType is a string (1 ..10) in which whitespaces are allowed. Solution: Specify that no ReceiverKind.RKParentType is indicated by only whitespaces in the string. Or change stringtype string (0 .. 10) for which string(0) indicates no ReceiverKind.RKParentType
Resolution: Add to 6.2.9 description that a lack of a Parent is indicated by an empty string.
Revised Text: Changes made as part of issue 12290
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13032: Section 6.3.6: RegisterReceiver (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Section 6.3.6: RegisterReceiver: Parameter AvailableAlertReceiver.ReceiverKind.RKParentType can not be filled by the caller with useful information because it is not relevant here. Solution: Remove this parameter
Resolution: See updated model, updated figure 6.3, change text for 6.3.6 RegisterReceiver as follows: replace parameters to be ALMASReceiver, String, String replace description as follows: This registers a receiver with ALMAS, the parameters are ReceiverHandle (for callback); ReceiverID (for use in all other methods, including UnregisterReceiver) and RKType to provide link to RK hierarchy.
Revised Text: Changes carried out as part of the updates for issu 12290 IDL changes for section 8.4 are captured in issue 12991 IDL changes for section 9.3.2 are captured in issue 13015 IDL changes for section 9.4.2 are captured in issue 13015 IDL changes for section 10.4 are captured in issue 12988
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13033: Section 6.2, 7.1: Name inconsistency (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Section 6.2, 7.1: Name inconsistency: AlternativeAction in section 6.2 is Alert_Responses in section 7.1. Solution: Use the same names.
Resolution: Use AlternativeAction in 7.1
Revised Text: XSD changes for section 7.1 are captured in issue 13013
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13034: ALMAS - IDL COM Corrections - Use SAFEARRAYs instead of the UDT array types ...TypeSet (almas-ftf)
Click here for this issue's archive.
Source: BAE SYSTEMS (Mr. Stephen Gilfillan, stephen.gilfillan(at)baesystems.com)
Nature: Uncategorized Issue
Severity:
Summary: We should be using the DCOM SAFEARRAY type instead of the UDT array types ALMAS_ReceiverKindTypeSet, ALMAS_DynamicMessageDataTypeSet, ALMAS_StaticMessageTypeSet, ALMAS_AlertDataExtraAttributesTypeSet.
Resolution: Update the DCOM IDL in section 10.2 and 10.4
Revised Text: IDL changes for section 10.2 are captured in issue 12988 IDL changes for section 10.4 are captured in issue 12988
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13037: Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction
Resolution: Update ALMAS Data Model IDL
Revised Text: IDL changes for section 8.2 are captured in issue 13017 IDL changes for section 9.2 are captured in issue 13017 IDL changes for section 10.2 are captured in issue 12988
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13042: ConfirmReceipt contains parameter ReceiverID (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: ConfirmReceipt contains parameter ReceiverID. This parameter seems to be not neccessary since ConfirmReceipt of one Responder is enough to enter the Received state. Solution: Remove parameter.
Resolution: Add to the description for Confirm Receipt of ALMASResponder in 6.3.6 "The ReceiverID field enables action & situation alerts to transition when sufficient confirmations have been received. 'Sufficient' is the 'actionee' for action alerts, and anyone for situation alerts. It can also be used for logging purposes.
Revised Text: Changes carried out as part of the resolution of issue 12290
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue
Issue 13169: Definition and behaviour of AlertDistributionNotification is not consistent (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: The name implies that the alert has been distributed, however the description says: "...has been received..." and the sequence diagram also shows that that the alertDistributionNotification is called as soon as the alert command has been received by ALMAS. Proposed solution: Since the intention of the AlertDistributionNotification is to confirm receipt of safety critical alerts, it is logical to include the distribution of the alert because a receiver alert command may effectively not result in a alert. This could happen because it is inhibited or there are no receivers available in the system. Therefore, in Figure 6.7 (Page 30) move sequence 3.1.1 to 3.1.6. Alternatively, alert distribution could be excluded, renaming alertDistributionNotification into alertCmdReceived
Resolution: Change text for AlertDistributionNotification , section 6.1.1, to be: "This is called as soon as a safety critical alert has been received by the ALMAS system. The onward distribution is notified through the StateChangeNotification callback."
Revised Text: Changes carried out as part of the resolution of issue 12290
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13170: Type of element name "Tag" not correct (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Issue: Type of element name "Tag" not correct. Proposed solution: Type should be string instead of integer.
Resolution: Tag element type should be string not integer. XML in section 7.1to be updated
Revised Text: XSD changes for section 7.1 are captured in issue 13013
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13171: Operation RaiseAlertFromOverrides (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Operation RaiseAlertFromOverrides: "Message: String" not correct. Proposed solution: Should be "StaticMessageDataSet: StringSet".
Resolution: Operation RaiseAlertFromOverrides needs to be able to set more than one message text and language. The proposal is to replace "Message: String" and MessageLanguage with a StaticMessageSet parameter.
Revised Text: The changes for Section 6.3 figure and 6.3.5 have been carried out as part of issue 12290 changes. IDL changes for sections 8.4, 9.3.2, 9.4.2, 10.4 are incorporated in the changed for issue 12991
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13172: Operation RaiseAlertFromOverrides (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Operation RaiseAlertFromOverrides: "SecondaryGrouping", "Persistent" and "ReliablyDistributed" omitted. Proposed solution: Add "SecondaryGrouping", "Persistent" and "ReliablyDistributed".
Resolution: Add in the additional parameters as proposed.
Revised Text: The changes for Section 6.3 figure and 6.3.5 have been carried out as part of issue 12290 changes. IDL changes for sections 8.4, 9.3.2, 9.4.2, 10.4 are incorporated in the changed for issue 12991
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13173: Operation Operation RemoveAlertsWithDynamicMessageData: (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Operation Operation RemoveAlertsWithDynamicMessageData: "RelatedObject Value" not defined in specification. Proposed solution: Replace "ObjectName: String" by "DataType: String" + "DataValue: String". These two together form the unique identification.
Resolution: Proposed solution: Replace "ObjectName: String" by "DataType: String" + "DataValue: String". Also remove mention of RelatedObject from description. Affects section 6.3.4, 8.4, 9.4.2, 10.4
Revised Text: Changes to section 6.3.4 carried out as part of the resolution of issue 12290 IDL changes for section 8.4 are captured in issue 12991 IDL changes for section 9.3.2 are captured in issue 13015 IDL changes for section 9.4.2 are captured in issue 13015 IDL changes for section 10.4 are captured in issue 12988 note that BSTR has to be used rather than string - as identified by issue 12988.
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13174: Struct ALMAS_GetFilledMessageText (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Struct ALMAS_GetFilledMessageText: No way is defined to return the filled message text. Proposed solution: Define a new topic, called ALMAS FilleMessageText, containing request_id and filled messages.
Resolution: Update IDL in section 9.3.2 to create a new topic called ALMAS_FilledMessageText which has a long long request_id and ALMAS_StringSet Messages.
Revised Text: IDL changes for section 9.3.2 are to add: struct ALMAS_FilledMessageText { long long request_id; ALMAS_DataModel::ALMAS_StringSet Messages; }; #pragma keylist ALMAS_FilledMessageText request_id
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13175: In the PIM, when creating an Alert ( RaiseAlertFrom...) (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: In the PIM, when creating an Alert ( RaiseAlertFrom...) it is required that the created Alert is returned as an out parameter (AlertID). This is omitted in the DCPS PSM. Here only the result in terms of successfull/not successfull is returned by means of a topic. Note that the created AlertID might be needed by the ALMASProducer for subsequent calls. Proposed solution: Define a new topic, called ALMAS CreatedAlert, containing request_id and AlertID.
Resolution: Update IDL in section 9.3.2
Revised Text: IDL changes for section 9.3.2 are as follows: struct ALMAS_CreatedAlert { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; }; #pragma keylist ALMAS_CreatedAlert request_id
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue
Issue 13176: Topic GetFilledMessageText needs ReceiverID attribute (almas-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Topic GetFilledMessageText needs ReceiverID attribute because a ReceiverID may set a specific language (Topic ALMAS_SetLanguage). Proposed solution: Add attribute ReceiverID to topic GetFilledMessageText
Resolution: Update IDL in section 9.3.2
Revised Text: IDL changes for section 9.3.2 are as follows: struct ALMAS_GetFilledMessageText { long long request_id; ALMAS_DataModel::ALMAS_AlertIDType AlertID; string ReceiverID;}; #prgma keylist ALMAS_GetFilledMessageText request_id
Actions taken:
December 19, 2008: received issue
July 23, 2009: closed issue