Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

The objective of the process is to ensure that normal service operation is restored as

quickly as possible and the business impact is minimized.

At a very high level, the Incident Management process includes eight process activities:

▪ Identification - Incidents are detected and reported.

▪ Logging - All relevant information relating to the nature of the Incident must be
documented.

▪ Categorization & Prioritization - Incidents are categorized and prioritized to


facilitate a swift and effective resolution.

▪ Initial Diagnosis - A diagnosis is carried out to try to discover the full symptoms
of the incident.

▪ Escalation - When the Service Desk cannot resolve the incident, the incident is
escalated for further support (functional escalation). If incidents are more
serious, the appropriate IT managers must be notified (hierarchic escalation).

▪ Investigation & Diagnosis - When there is no known solution, the incident is


investigated.

▪ Resolution & Recovery - Once the solution has been found, the issue can be
resolved.

▪ Incident Closure - The Service Desk confirms that the incident is fully resolved
and that the user is satisfied and then the incident can be closed.

Reference qualifiers

Reference qualifiers to create filters that restrict the data that is returned for a reference
field.

Simple reference qualifier


Simple reference qualifiers use AND/OR statements (conditions) to create simple filters. Use
simple reference qualifiers when filtering on conditions such as whether a company is
active, a user has a specific role, and/or a caller is in a specific time zone. Simple reference
qualifiers can have a maximum of 13 reference qualifier conditions.

Dynamic reference qualifiers


Dynamic reference qualifiers enable you to use a dynamic filter option to run a query
against a reference field to filter the returned data set. Dynamic filter options are stored
filters that can contain encoded query strings, JavaScript, or script includes, and can be used
in multiple dynamic reference qualifiers.
System Definition → Dynamic Filter Options.

Ref table-sys_filter_option_dynamic
Write Business rule;
{
Var gr=new GlideRecord(sys_user)
Gr.addquery();
Gr.Query();
In Ref Qualifier:new(sxcripinclude name).function();

Advanced reference qualifier


Advanced reference qualifiers enable you to define an inline encrypted query string or
JavaScript (actual code or the name of an existing script include or business rule) filter
directly in the Reference qual field of the reference qualifier.
example of a JavaScript call is javascript:new myScriptInclude().my_refqual(). This
code calls the function my_refqual() in the script include myScriptInclude(). T

Few of the most common problems that occurs in Update set:

• Error type: Missing object


Example: “Could not find a record in sys_ui_policy referenced in this update”
• Error type: Collision
Example: ”Found a local update that is newer than this one”
• Error type: Uncommitted update
Example: “Could not find a table field (u_case.u_reference) referenced in this update, but
did find it in another uncommitted update set
• Error type: Table to be deleted has data
Example: “Found a row in the table that is going to be deleted”
• Error type: Application scope validation issue
Example: “Could not find a record in sys_scope for column sys_scope referenced in this
update.

SLA
A Service Level Agreement (SLA) is a contract between an internal service provider and an external
end customer. Service Level Agreements define the range and quality of the covered services.
Within the Service Desk, SLAs especially define the time spans in which tickets must be accepted and
solved in order to avoid escalation.

An Operation Level Agreement (OLA) is an agreement between an internal service provider and an
internal customer. Operation Level Agreements define the range and quality of the covered
services.

An Underpinning Contract (UC) is a contract between an external provider and an internal end
customer. Underpinning Contracts define the range and scope of the covered services.

TARGETS
Response SLA is calculated as a time between the incident creation and its acknowledgement
by the assignee.
Resolution SLA is calculated as a time between incident creation and its resolution.

Retroactive Pause: Enabling this property ensures that the new task SLA record gets any
pause time that would have been accumulated during the period between the retroactive
start time and now. This pause time increases the breach time with the appropriate amount.
Rest and Soap
Difference

1) SOAP is a 1 1) REST is an architectural style.


protocol.
.
2) SOAP stands for Simple Object Access Protocol
2. 2) REST stands for REpresentational State
Transfer.

3) SOAP can't use REST because it is a


protocol. 3) REST can use SOAP web services because it is
a concept and can use any protocol like HTTP,
SOAP.

4) SOAP uses services interfaces to expose the


business logic 4) REST uses URI to expose business logic.

5) JAX-RS is the java API for RESTful web


5) JAX-WS is the java API for SOAP web services services.

6) REST does not define too much standards like


6) SOAP defines standards to be strictly SOAP.
followed.

7) REST requires less bandwidth and resource


than SOAP.
7) SOAP requires more bandwidth and resource
than REST
8) RESTful web services inherits security
measures from the underlying transport.

8) SOAP defines its own security


9) REST permits different data format such as Plain
text, HTML, XML, JSON etc.

9) SOAP permits XML data format only 10) REST more preferred than SOAP.

10) SOAP is less preferred than


REST.

HTTP response status


HTTP response status codes indicate whether a specific HTTP request has been
successfully completed. Responses are grouped in five classes:

Informational responses (100–199)


Successful responses (200–299)
Redirects (300–399)
Client errors (400–499)
Server errors (500–599)
JSON vs XML
Both JSON and XML can be used to receive data from a web server.

The following JSON and XML examples both define an employees object, with
an array of 3 employees:

JSON Example
{"employees":[
{ "firstName":"John", "lastName":"Doe" },
{ "firstName":"Anna", "lastName":"Smith" },
{ "firstName":"Peter", "lastName":"Jones" }
]}

XML Example
<employees>
<employee>
<firstName>John</firstName> <lastName>Doe</lastName>
</employee>
<employee>
<firstName>Anna</firstName> <lastName>Smith</lastName>
</employee>
<employee>
<firstName>Peter</firstName> <lastName>Jones</lastName>
</employee>
</employees>

JSON is Like XML Because


• Both JSON and XML are "self describing" (human readable)
• Both JSON and XML are hierarchical (values within values)
• Both JSON and XML can be parsed and used by lots of programming
languages
• Both JSON and XML can be fetched with an XMLHttpRequest

JSON is Unlike XML Because


• JSON doesn't use end tag
• JSON is shorter
• JSON is quicker to read and write
• JSON can use arrays
The biggest difference is:

XML has to be parsed with an XML parser. JSON can be parsed by a


standard JavaScript function.

Why JSON is Better Than XML


XML is much more difficult to parse than JSON.
JSON is parsed into a ready-to-use JavaScript object.

For AJAX applications, JSON is faster and easier than XML:

Using XML

• Fetch an XML document


• Use the XML DOM to loop through the document
• Extract values and store in variables

Using JSON

• Fetch a JSON string


• JSON.Parse the JSON string

You might also like