Cisco Provisioning Management Gateway

Transcription

1 The (PMG) is a generic provisioning and management application that provides the necessary workflow component between the Service Provider (SP) IT or Operations Support Systems (OSS) applications and the Cisco provisioning Broadband Access Center (BAC). These OSS applications include service management and custom care systems. This guide describes the PMG operations, components and concepts, and services in detail. While PMG is designed to be a generic product, this document describes the concepts specific to this release. This chapter describes PMG components and concepts as used in the current release. PMG Overview, page 1 PMG Event Subscription, page 3 PMG Logging, page 7 PMG Profiles, page 12 PMG Overview The PMG is a generic application suitable for any TR-069 deployment with the BAC. The application provides an Extensible Markup Language (XML) interface over Hypertext Transfer Protocol (HTTP) based Application Programming Interface (API) to the OSS that hides the complexity of the BAC API. The PMG provides the ability to customize a deployment by using a profile that defines the elements of the API (such as messages, parameters, and so on) that are applicable. The PMG provides the following functionality: Interfaces to the OSS system for device provisioning and management. XML messages for provisioning and management. Interacts with the BAC and HNB-GW. Interfaces with the HNB-GW via RADIUS for dynamic whitelist. Reports events to the subscriber/oss. Reports SNMP alarms for PMG service related events. Interfaces with the HNB-GW via RADIUS for dynamic whitelist. 1

2 PMG Overview For requests from the OSS, the PMG accepts TCP connections, receives an HTTP request with XML payload and provides response in HTTP response with XML payload. The connection can remain persistent for subsequent requests unless it is closed by the client or times out. For notifications, the PMG establishes a TCP connection to an IT / OSS / BSS, sends an HTTP request with XML payload and gets confirmation in HTTP response. The connection can remain persistent for subsequent notifications unless closed by target or times out. The PMG API is defined by a profile, which is an XML document that describes the inbound messages that the PMG supports. The XML schema provides a means for defining the structure, content, and semantics of the XML document. The XML schema for the profile specifies the inbound requests, the required elements, excluded elements, ignored elements, and the applicable parameters. These parameter elements include name, type, readable, writable, deletable, and source type along with optional validation and source key. PMG is installed as part of the OVA installation. This table lists a few standard HTTP status codes used in validating the PMG messages: Table 1: PMG HTTP Status Codes HTTP Status Codes 200 OK 400 Bad Request 503 Service Unavailable Description Occurs for any response containing a valid PMG message response (which in turn may contain an application layer error). Occurs when the request received does not contain a valid PMG message (for example, wrong encoding). Used when the service is unavailable, typically due to high load. The client must resend the service request. Following is the send.url for posting an XML message from the OSS or Poster to the PMG: name/ip address>:8083/pmg Where, <host name> is the host name of the Central Node. <IP address> is the eth1 of the Central Node is the port number. /pmg is the path. Digest authentication is supported in PMG. To add any new pmguser or pmgadmin user, log in to DCC UI as a pmgadmin and create new users. 2

3 PMG Message Flow PMG Message Flow The following is the flow of PMG messages: 1 OSS establishes an HTTP connection with the PMG service url. 2 OSS sends a message to PMG with the digest authentication credentials. 3 PMG receives the message and validates the content-type as application/xml or text/xml. 4 PMG validates that the message is valid XML. 5 PMG validates that the message complies with PMG XML Schema Definition (XSD). 6 PMG determines the message type by examining the root node name. 7 PMG determines if the message type is part of the configured profile. 8 PMG makes business orchestration by invoking PMG API. 9 Construct the response message and sent with HTTP 200 OK response message. LUS Organized Directory Structure for AP PM Files Currently all the APs upload PM files to LUS server under the same directory (base path). Therefore, if the number of APs are more, then the directory is unmanageable. This feature is added to categorize the APs based on AP's associated group, and upload all these APs PM files to LUS into a same sub directory under base path. (sub directory name will be the associated group name.) New property "ap.upload.url.suffix.group " is added in PMGServer.properties file to enable this feature. By default value of this is "NO_GROUP", means feature is disabled and the current behavior will continue. Possible values of this property are Area/FemtoGateway/Enterprise/Site (Possible FRM group types). For example: If ap.upload.url.suffix.group = Area, A P-1,2,3 are associated to Area-1, AP-4,5,6 are associated to Area-2, then the uploaded PM files will be structured as below: /opt/cscouls/files/uploads/area-1/ AP1-stats_1.xml AP1-stats_2.xml AP2-stats.xml AP3-stats.xml /opt/cscouls/files/uploads/area-2/ AP4-stats.xml AP5-stats.xml AP6-stats.xml When this feature is enabled, PMG will set "FC-LOG-PERIODIC-UPLOAD-URL" custom property at device level for all newly registered APs. The same can be added to existing APs with ReAssign API. PMG Event Subscription The subscriber should follow these steps for subscribing to the PMG events: 1 Send the getalleventtypes message (subscribe.xml) to PMG for receiving all the supported events. 3

4 PMG Event Subscription Each subscriber can subscribe to all the events or selected events, and can have multiple (maximum 3 and minimum 1) notification url for one subscriber. PMG picks up one url and delivers the event. If that URL1 is not reachable, then PMG picks up the next url for event delivery. PMG event subscription supports these events: AssignedData, FirmwareUpgraded, GroupCreated, GroupUpdated, GroupDeleted, LocationStatus, Online, ServiceError, ServiceOperational,Tampered, UserPasswordExpiryNotification, CustomValueChange, and IpAddressUpdate.. PMG accepts three number of subscribers by default. Following is the sample xml request for event subscriptions: <Subscribe subscriber-name= OSS-1 > <URL> </URL> <URL> </URL> <URL> </URL> <Event name= AssignedData > <Parameter name= ecgi > <Event name= Groups isenabled=false> </subscribe> Following is an example xml: <Subscribe xmlns=" xmlns:xsi=" xmlns:xsd=" xsi:schemalocation=" pmg-messages-v3_0_0.xsd" subscriber-name='testlab-oss-1'> <TxnID>subs-trans </TxnID> <URL> <Events> <Event name='assigneddata' isenabled='true'> <Event name='groupcreated' isenabled='true'> <Event name='groupupdated' isenabled='true'> <Event name='groupdeleted' isenabled='true'> <Event name='firmwareupgraded' isenabled='true'> <Event name='locationstatus' isenabled='true'> <Event name='online' isenabled='true'> <Event name='serviceerror' isenabled='true'> <Event name='serviceoperational' isenabled='true'> <Event name='tampered' isenabled='true'> <Event name='ipaddressupdate' isenabled='true'> <Event name='userpasswordexpirynotification' isenabled='true'> </Events> </Subscribe> 2 The subscriber can send this subscribe message from any host by specifying the subscriber name and the list of notification URL. Subscribed events are specified in the <Event> element, and events are enabled by default. Changing the Enabled state of particular event to false, to disable the event. Following is an example: <Event name='locationstatus' isenabled='false'> 4

5 RMS Alarm Handler 3 The subscriber can customize the events by specifying the parameter names that the notification server prefers to receive. If the parameters are not specified, then the notification will contain all the parameters of an particular event. If the events are not specified, it indicates that the subscriber has subscribed to all the events. 4 The subscriber can update event subscription by sending subscribe message with the updated set of additional events and removing previously subscribed events. For example, the subscriber can subscribe to events by posting the subscribe.xml message using the url address of central node>:8083/pmg to receive the notifications. RMS Alarm Handler RMS alarm handler raises the AP Reachability Alarm and AP location Verification Alarm. AP Reachability Alarm RMS has introduced a new alarm AP Reachablity Alarm with the severity "Major". The alarm raises whenever the AP is abruptly down or Issue in the network connection between FAP and RMS. The scenarios are as follows: RMS raises AP Reachability alarm if the current request for connection request has failed and previous one is passed. RMS clears the AP Reachability alarm if the current request for connection request has passed and previous one is failed. RMS forwards AP Reachability alarm to Prime Central for further processing. RMS treats this alarm in a similar way as it treats any other FAP alarm. For example, adding FAP ID, DN Prefix and so on while sending this alarm to Prime Central. RMS defines a property using which operator can turn on/off generation of this alarm. RMS schedules masscr.sh to run every 10 minutes by default. AP Location Verification Alarm RMS raises a Location Verification Alarm with the severity Major if the location verification passes or fails based on these scenarios: RMS raises Location Verification alarm if the current location verification has failed and the previous location verification was passed. RMS clears Location Verification alarm if the current location verification has passed and previous location verification was failed. RMS forwards Location Verification alarm to Prime Central for further processing. RMS treats this alarm in similar way as it treats any other FAP alarm. For example, adding FAP ID, DN Prefix, and so on while sending this alarm to Prime Central. 5

6 RMS Alarm Handler RMS defines a property using which operator can turn on/off for generation of this alarm. The PMG Server Properties file, (/rms/app/pmg/conf/pmgserver.properties) must be configured as shown below for enabling the Alarm Handler Feature. #Alarms #Following parameter is used to enable/disable the EPM alarm feature. #1:Enable, 0:Disable pmg.alarms.snmp.epm.alarmhandler=1(enable by default) pmg.alarms.snmp.epm.alarmhandler.port=4678 (Port) pmg.alarms.snmp.epm.nummanagers=1 #<Prime central IP> pmg.alarms.snmp.epm.manager.address.1= pmg.alarms.snmp.epm.manager.port.1=162 pmg.alarms.snmp.epm.manager.community.1=public #1:Enable AP reachability alarm, 0:Disable pmg.alarms.snmp.epm.apreachability=1 #Connection Request Timer, By Default this is 10 min. Can be increased to interval of 60 min pmg.alarms.snmp.epm.apreachability.interval=10 #Rate at which Connection Request is Triggered. By Default this Should be 10 pmg.alarms.snmp.epm.apreachability.rate=10 pmg.alarms.snmp.epm.apreachability.devices.max=5000 #idfile: A absolute path to a file with a list of devices or group IDs (one per line). # Provide the Complete Path with ciscorms permissions pmg.alarms.snmp.epm.apreachability.idfile= #type: Specifies the content of the list file as either devices or a configured group type (Available types are : all, devices, provgroup, cos, Area, CELL-POOL, Enterprise, FRM-Group-Type-Meta-Data, FemtoGateway, Management, Pool-Type-Meta-Data, SAI-POOL, Site, system) pmg.alarms.snmp.epm.apreachability.type=all #1:Enable AP location check, 0:Disable pmg.alarms.snmp.epm.aplocation=1 #Serving Node Eth_0 Ip Address pmg.alarms.snmp.epm.serving.address= For the first time usage of the alarm handler, the below changes should be made in the PMGServer.properties file under the path /rms/app/pmg/conf. 1 Add the PrimeCentral IP/SNMP Address: #<Prime central IP> For example, pmg.alarms.snmp.epm.manager.address.1= Provide the Eth_0 Serving Node IP Address #Serving Node Eth_0 Ip Address For example, pmg.alarms.snmp.epm.serving.address= Provide the path of the file location # Provide the Complete Path with ciscorms permissions For example, pmg.alarms.snmp.epm.apreachability.idfile=/rms/app/pmg/conf/idfile.txt 4 Modify the below Parameter value as required. For example, if the alarm handler needs to be triggered for all devices, then provide all as mentioned below. pmg.alarms.snmp.epm.apreachability.type=all User Guidelines 1 RMS issues Connection Request (CR) every 10 min (by default) as configured in the PMG Server Properties file. 2 CR is issued based on the configuration in the PMG Server properties file. For example: pmg.alarms.snmp.epm.apreachability.idfile= /rms/app/pmg/conf/ idfile.txt 6

7 PMG Logging #type: This specifies the contents of the list file as either devices or a configured group type. The available types are: all, devices, provgroup, cos, Area, CELL-POOL, Enterprise, FRM-Group-Type-Meta-Data, FemtoGateway, Management, Pool-Type-Meta-Data, SAI-POOL, Site, system. pmg.alarms.snmp.epm.apreachability.type=all (This should be changed based on the configuration.) This file should have ciscorms permissions, for example: chown ciscorms:ciscorms idfile.txt chmod 744 idfile.txt 3 The Alarm handler logs in to the path (/rms/log/alarmhandler/alarmhandler.console.log). PMG Logging The PMG is capable of logging all requests and responses to and from the OSS, and to and from the BAC. The PMG logging automatically rolls its log files on a daily and file size basis. The path for pmglogs is /rms/log/pmg. This table lists the different types of PMG logs. By default a maximum of five days of compressed log files are maintained for various PMG log files. Table 2: Different Types of PMG Logs PMG Logs Performance Logs Audit Logs Message Logs Syslog Description The Performance log determines the performance statistics and consists of two files, one for individual message performance and the other periodic roll-up performance metrics. The Audit log logs all interactions with the individual provisioning system components and changes, to the device configuration. The OSS HTTP Message logs are used for testing and message tracking purposes. PMG server status will be logged when PMG is started/stopped/restarted. Syslog contains the Alarm messages of PMG server. Thus, PMG logging is useful in determining device performance and ensuring proper processing with the BAC. Alarm information is logged in the syslog. The syslog messages can be found in /var/log/local0.log. In addition to the logs mentioned above, the server start/stop will also be logged in syslog. The server, pmgserver, must be started with the user specified as ciscorms. All PMG logs are stored in the directory defined in the /rms/log/pmg/ environmental variable with a "/pmg" added. 7

8 PMG Performance Logs PMG Performance Logs The Performance logging consists of two files; one for individual message performance and the other hourly roll-up performance metrics. Individual Performance Log File The performance log for individual messages is output to the file "pmg-msg-perf.csv" and is stored in the directory /rms/log/pmg. The Performance log file is in the CSV format and begins with a header row followed by the individual message performance data. An example of the individual performance logs is shown here: T01:01: Block ead1eb bb 00223A T01:01: Unblock ead1eb bb 00223A T01:01: Update ead1eb bb 00223A T01:01: GetStoredData ead1eb bb 00223A T01:01: Block ead1eb bb 00223A T01:01: UnBlock ead1eb bb 00223A T01:01: Unknown Unknown Unknown T01:01: Unknown Content Unknown Unknown T01:01: XML Parse error Unknown Unknown Following are the headings of the fields in the log file and their descriptions: timestamp is the date and time of the received message. The timestamp is represented in the ISO 8601 format "YYYY-MM-DDThh:mm:ss.fffZ", where: YYYY-represents the four-digit year MM-represents the two-digit month DD-represents the two-digit day of the month T-is the time delimiter hh-represents the time in hours mm-represents the time in minutes ss-represents the time in seconds fff-represents the time in milliseconds Z-represents the zone designator for the zero (Co-ordinated Universal Time) UTC off set, if the time is in UTC msg name-the message name as found in the XML root element trans id-the transaction ID in the message eidthe device ID for the record. If the message is called with a Secondary ID, the EID must be looked up and used msg process time ms-the message processing time of the message processor in milliseconds, with the BAC processing time removed BAC process time ms-the BAC processing time in milliseconds 8

9 PMG Performance Logs total msg process time ms-the total message processing time in milliseconds that includes time in un-marshaling the message, message processing time, BAC processing time, and the response time in message marshaling. To track the performance of unknown messages, messages with XML parser errors and messages that are not of XML content are also logged in the individual performance log file. Following are some of the logging details for unknown messages: All unknown messages have the message name, transid, and EID as "Unknown". All message XMLs that fail to parse, have the message name as "XML Parse error" with transid and EID as "Unknown". All messages that are not of content type application/xml or text/xml have the message name as "Unknown Content", with transid and EID as "Unknown". The audit logging is output to the file "pmg-audit.log" and is stored in the directory /rms/log/pmg. The audit logs are used to identify the workflow from the receipt of a PMG message to the response back to the OSS. The audit logs will be rotated after 12 am when the first log entry comes in each day or if larger than 50 MB in size. Some of the archived log files are maintained until the files consume configured disk space threshold. For details, see Cleaning Up PMG, Upload Server, and DCC UI Logs. For log files that are not configured for disk space thresholds, the individual archived logs are maintained for five days on the Central node after which they are removed from the Central node. Periodic Performance Log File The periodic performance log file is a summary of each message performance from the start of PMG or for the last period defined. The period is specified by the pmg.perf.periodic.log.interval.milli.seconds property in the dcc.properties file. The period is specified in milliseconds. If this property is not set in the dcc.properties file, the default value of (1 hour) is used. For example, if the period is set to , which corresponds to 15 minutes, and the PMG starts at 2:03, the first log is printed at 2:18 and then at 2:33 and so on. The periodic performance log files are output to the file "pmg-perf-periodic.csv", and are stored in the directory /rms/log/pmg. The periodic performance log file is in csv format and begins with a header row followed by a performance summary for each message. An example of the messages in the file for the period performance logs is shown below for 15 minute intervals: T16:41:49.735Z,899,GetAllFRMPools,96,96,96,1,0,245,524,0, T16:41:49.736Z,899,GetAllFRMPoolTypes,113,118,108,2,0,424,1486,0, T16:41:49.737Z,899,GetAllFRMGroupTypes,447,767,272,3,0,642,8694,0, T16:41:49.737Z,899,GetAllFRMGroups,157,157,157,1,0,241,6914,0, T16:56:49.735Z,899,GetLiveData,145,145,145,1,0,606,283,0, T16:56:49.736Z,899,GetAllFRMPools,69,70,68,2,0,487,1047,0, T16:56:49.737Z,899,GetAllFRMPoolTypes,99,108,91,2,0,424,1486,0, T16:56:49.737Z,899,GetAllFRMGroupTypes,204,211,200,3,0,642,8694,0, T16:56:49.738Z,899,GetStoredData,259,271,248,2,0,448,35272,0,10 The headers for the fields in the periodic performance summary file are described here: period end-the summary period end timestamp in the ISO 8601 format. The timestamp is in the format "YYYY-MM-DDThh:mm:ss.fffZ", where time is represented in milliseconds 9

10 PMG Alarm Logs summary period sec-the time interval in milliseconds, for receiving the messages during the summary period msg name-the message name received during the summary period avg response time ms-the average response time in milliseconds max response time ms-the maximum response time in milliseconds min response time ms-the minimum response time in milliseconds num msgs-the total number of messages received during the summary period num errors-the number of errors occurred during the summary period To track the performance of unknown messages, messages with XML parser errors and messages that are not of XML content are also rolled up in the periodic performance summary file. Following are some of the logging details for unknown messages: All unknown messages have the message name as "Unknown". All message XMLs that fail to parse have the message name as "XML Parse error". All messages that are not of content type application/xml or text/xml have the message name as "Unknown Content". The periodic performance logs are maintained for five days on the Central node after which they are removed from the Central node. Each periodic performance log file is rotated after 12 am when the first log entry comes in or if the file size exceeds 10 MB. PMG Alarm Logs The PMG alarms are sent to Prime Central or any alarm monitoring entity via the Fault Management server. Table 3: PMG Alarm Log Messages Alarm Condition Connection with the RDU lost Connection with RDU established Radius connection lost Radius connection restored PMG connection limit exceeded PMG connection limit exceeded PMG Server start Alarm Level Critical Clear Minor Clear Warning Major Warning Alarm Text Alarm raised: Type=RDU Connection Alarm resolved: Type=RDU Connection Alarm raised: Type=Radius Connection Alarm rersolved: Type=Radius Connection Alarm raised: Type=PMG Connection Alarm raised: Type=PMG Connection Alarm resplved Type= PMG Status 10

11 PMG Syslogs Alarm Condition PMG Server stop Alarm Level Major Alarm Text Alarm raised Type= PMG Status PMG Syslogs The alarms logged in pmg-alarms.log are logged in the syslog (/var/log/local0.log). In addition to the above mentioned logs, the server start/stop are also logged in the syslog. For the statements to appear in the syslogs, the udp port has to be uncommented in /etc/rsyslog.conf. These parameters, (if commented) need to be uncommented in rsyslog.conf. #$ModLoad imudp.so #$UDPServerRun 514 The rsyslog needs to be restarted: /etc/init.d/rsyslog restart PMG Message Logs The PMG includes inbound message logs for inbound message tracking. This logging is output to the file "pmg-inbound-msg.log", and is stored in the directory /rms/log/pmg. The PMG also includes outbound message logs for outbound message tracking. This logging is output to the file "pmg-outbound-msg.log", and is stored in the directory /rms/log/pmg. Inbound message logs and outbound message logs are rotated after 12 am when the first log entry comes in or if the file size exceeds 50 MB. : The individual logs are maintained for five days on the Central node after which they are removed from the Central node. PMG Status Monitoring Use these commands to monitor the status of the PMG server and start or stop the server. Procedure Step 1 god status PMGServer Verifies the status of the PMG server. The server states can be up (running), unmonitored (stopped), init (intermediate). Example: This example shows sample output when the server is up: [rms-aio-central] /home/admin1 # god status PMGServer PMGServer: up 11

12 PMG Profiles This example shows sample output when the server is stopped: [rms-aio-central] /home/admin1 # god status PMGServer PMGServer: unmonitored Step 2 god start PMGServer Starts the PMG server. Example: This example shows sample output when the server is started. [rms-aio-central] /home/admin1 # god start PMGServer Sending 'start' command The following watches were affected: PMGServer Step 3 god stop PMGServer Stops the PMG server. Check the status of the PMG server before starting or stopping the server. Wait for some time after executing the command as it can take 10 to 12 seconds. Example: This example shows sample output when the server is stopped: [rms-aio-central] /home/admin1 # god stop PMGServer Sending 'stop' command The following watches were affected: PMGServer PMG Profiles A PMG profile defines the messages used for the configuration and activation processes. The profile specifies the inbound requests that are used along with the required, ignored, and excluded elements. The PMG profile also contains a number of exclusions, but does not add element requirements. The PMG profile is referred to as pmg-profile.xml in the server. Using the pmg-profile.xml, the operator can add/remove/exclude/ignore for any message. For all PMG messages, either an EID or SecondaryID is specified as the device ID. The device search is performed using the SecondaryID which is the device's Fully Qualified Domain Name (FQDN) in BAC or with the EID which is the device's DeviceID property in the BAC. Profiles are used to specify the subset of messages, elements, and parameters to be used in a given deployment. A Profile is a way to configure the generic PMG to deployment-specific requirements. The PMG profile contains the Parameter Definition section, which defines the names and types of the supported parameters. 12

13 Parameter Definitions When pmg-profile is customized for the first time, the PMG server must be restarted. Place the customized pmg-profile.xml in the /rms/app/rms/conf/ directory. The path for the default pmg-profile.xml is /rms/app/rms/doc/pmg/pmg-profile.xml. Parameter Definitions Some PMG messages support the parameter structure to add, update, delete, or retrieve parameters. The PMG profile contains the Parameter Definition section, which defines the names and types of the supported parameters. This table lists some of the parameter elements that are defined in the parameter definition. Table 4: Parameter Elements and Description Parameter Elements Name Type Description The parameter name or the alias used in the message. The type of the parameter that can be: String Integer (BAC custom property which is an integer) Unsigned integer (BAC custom property which is of the type Long) Decimal Boolean Date/Time Source Type The type of the source that includes: DeviceParameters An example of BAC API constant: DeviceDetailsKeys.DEVICE_ID. DeviceProperty (BAC property or custom property) Writable Readable Deletable Indicates if the parameter is writable (can be added or updated). Indicates if the parameter is returned by a get. Indicates if the parameter can be deleted. 13

14 Validating Modified pmg-profile File Parameter Elements Validation Description Defines the validation to use on a Writable parameter value and is defined by the following: Type - defines the type of validation that can be: A range, used to validate numbers. The expression element is of the format [low:high], where "low" is the lowest number in the range, or empty if there is none, and "high" is the highest number in the range or empty if there is none. A Regular expression. The expression element contains a regular expression that is used to match the value. Expression - Expression as defined by the type, either a range or regex expression. Length - Length is used to validate the length of string type parameter. Following is an example for validation: <ParameterDefinition> <Name>MAX-TRANS-PWR</Name> <Type>int</Type> <SourceType>DeviceProperty</SourceType> <Writable>true</Writable> <Readable>true</Readable> <Deletable>true</Deletable> <Validation> <Type>range</Type> <Expression>[-100:10]</Expression> </Validation> </ParameterDefinition> Validating Modified pmg-profile File The modified pmg-profile.xml file should be validated with the latest pmg-profile schema file (XSD file). To validate the file, use the following command: xmllint --noout --schema <xsdpath> <xmlpath> xmlpath = full path of the pmg-profile.xml which is modified xsdpath = full path oflatest schema file for the pmg-profile.xml. Normally it is present in the central node at /rms/app/rms/doc/pmg/pmg-profile-v2_0_0.xsd Example: xmllint --noout --schema /rms/app/rms/doc/pmg/pmg-profile-v2_0_0.xsd /rms/app/rms/doc/pmg/pmg-profile.xml On successful validation, the following message is displayed: "/rms/app/rms/doc/pmg/pmg-profile.xml validates" If the validation fails, it displays where and what the issue is in the xml file. 14