For external alert definitions, the Alerts module enables you to push external alerts through a Web service.
Enabling a Dashboard Framework model for a Web service only makes sense for standalone Web application deployments, so you have to create a separate project and deploy it as an application server WAR to expose the Alerts Import Service.
The general steps are described below.
Creating an external alert definition
Use the Manage Alerts portlet to create an external alert definition.
Creating a Web Service on the server
- Create a new WebSphere Dashboard Framework project and include the following feature sets:
Alerts Module
Dashboard Framework
- Create a new model named AlertImporter.
- Add a Schema builder (named alertSchema) to this model. Use the following builder inputs:
- Schema Source Type - Existing URL/File
- URL or Schema File Location - /WEB-INF/solutions/alerting/schemas/alerting.xsd
- Add a Linked Java Object builder (named ImporterLJO). Use the following builder inputs:
- Class Name - com.bowstreet.solutions.alerting.admin.ImportedAlertsLJO
- Add a Web Service Enable builder. Use the following builder inputs:
- Method - IXml ImporterLJO.importAlerts(IXml)
- Response SchemaPath - alertSchema/AlertImportResponse
- Return value name - AlertImportResponse
- Argument 1 Name (IXml) - alerts
- Argument Schema Path - alertSchema/Alerts
- Change other inputs if necessary.
- Share the same alert repository with your original Dashboard project containing the Alerts module.
For more information, see the topic called "Sharing a persistence manager between projects" in the WebSphere Dashboard Framework Information Center.
- Deploy your project as an application server WAR.
- Verify the WSDL by entering this URL: http://localhost:10038/iWDF602/webengine/AlertImporter/Action\!getWSDL
Creating a Web service client
How you write your Web service client depends on what client technology you choose. To ensure a successful import operation, pay attention to the following elements when you generate your input XML.
- AlertID - this value must be an existing external alert definition ID
- Priority - the Alerts module supports three values: 1 (High), 2 (Normal), and 3 (Low). If you use other values, the import will not fail, but the results will be unpredictable.
- CreationDate, ExpirationDate - all date values should be in the format "2006-02-16T14:31:59Z". If they are not in that format, the import will fail because it will not be able to parse the date value.
Basic sample input XML:
<Alerts xmlns="http://bowstreet.com/2002/10/AlertingSchema">
<Alert>
<AlertID>AlertID_Example_External_Alert</AlertID>
<DisplayName>sampleExternalAlert</DisplayName>
<VersionID>123</VersionID>
<UniqueID>123</UniqueID>
<CategoryID>sampleExternalAlert</CategoryID>
<DisplayCategory>sampleExternalAlert</DisplayCategory>
<Priority>1</Priority>
<DisplayText>sampleExternalAlert</DisplayText>
<DetailedDisplayText>sampleExternalAlert</DetailedDisplayText>
<CreationDate>2006-02-16T14:31:59Z</CreationDate>
<ExpirationDate>2007-02-16T14:31:59Z</ExpirationDate>
For information about other elements, refer to the schema file /WEB-INF/solutions/alerting/schemas/alerting.xsd.
Verifying the results
Test your Web Service client. To verify the result:
- XML-file persistence manager - You should see a new XML file generated under Your portlet war\WEB-INF\solutions\alerting\xml_persistence\generic_alerts.
- Database persistence manager - You should see a new record in table IBMAE_GNRCALRT.
Tip: The Alerts Module Examples feature set includes sample models that use external alert definitions. Include that feature set in your project to see the samples.