CA Service Management

Hola TMACUL espero estés bien, 

mi consulta es la siguiente:

Se podría hacer una restricción para que los roles: Analista de Nivel 2 y Gestor de Nivel 2 no utilicen el estado "Cerrado" en la gestión de problemas pero si se pueda utilizar en solicitudes e incidentes? Adicional tengo un rol de "Gestor de problemas" que si necesita usar el estado cerrado.

Agradezco tu ayuda. 

Saludos

Hola Jperezr ,

Lo necesita usar el campo active_flag.

call_req 

Saludos.

Hola Tiago

Cual sería el constraint para restringir que un ticket sea editado en estado inactivo?

Gracias

HI Johnny_2302 ,

01.   The only way to show CI's for Employees::. You need to update the access type for: Licensed

"Licensed?
Determines whether this contact is a licensed access type. Contacts assigned to unlicensed access types can only view or update their own personal data."

Create an Access Type - CA Service Management - 14.1 - CA Technologies Documentation 

Regards

Hi Tiago,

In the employee data partition, i want to display the CIs of the affected end user, so is it possible to change below code

resource_contact = @root.id

to 

resource_contact = @affected_enduser.id

En efecto Tiago, Es ese el planteamiento.

Mostrar tickets de mi grupo y tickets que sean hijos.

Regards,

Hola julio.ramos,

Por favor podría describir exactamente la necesidad?

Por algun caso: Presentar solamente tickets de mi grupo y que son hijos?

Saludos

Tiago Macul

Hi Tiago and thanks for you time  to answere.

I used this code and the result is ok but i get all the tickets having a parent. From this result i just need the tickets having a parent owning to my group.

Looking the behavior for the references in data partitions it seems like this can´t be possible because i need to evaluate a list of tickets using something like

"parent is not null and parent´s group = my group"

Regards,

Hi julioRamos ,

I do known if i got your question, but however it's something like that

Type/Tipo: View/Exibir

Table/Tabela/Tabla:Call_Req

view tickets where the own group

(group.[group]group_list.member IN (@root.id))

OR

parent is not null

Regards

Hi Tiago,

I have a question.

If a need to view tickets where the own group and orther tickets where the first ones are parent but with different groups?

HI jmayer and Gutis,

  I appreciate your comments collaborating with community.

  I Agree, this command degrades performance but some times is required, however we can apply alternatively the Giedrius procedure.

I already wrote about  Performance SQL – Tiago Macul.

Regards

Thanks Tiago for the update!

Yes agree

IN is more efficient as IN statement will walk trough the list for values match (comparable to = but on multiple value) when a LIKE statement is doing a pattern matching to find the correct values (character by character) and either if modern SQL engine are now well optimized for it this is still a significant difference in terms of resource consumption and time to return data.

Of course all this is mainly dependent of the indexing of your database. If the field you are looking for is well indexed in the database LIKE statement may be faster in certain case as IN statement is not index aware.

We are deviating from the initial subject but this is where DBA role come crucial (and many time underestimated) for the healthy of your application that rely strongly on SQL performance

/J

I fully agree with You. But even when it is absolutly necessary to use dot references I prefer IN instead of LIKE e.g. (group.organization.name IN ( '%org%' ))

agree with you Gutis but still want to discourage as much I can to use dotted etc when not absolutely necessary.

I have a case one time where my team upon client request was creating stored queries to add in scoreboard with group.organization.name like '%org1%' don't seems to be a problem and be really more easy to do until they created 200 queries like this and corresponding scoreboard for analyst containing 50 of them refreshing every 3mn.

I can tell you that when you have 2000 concurrent analysts connected and either if you have a big server this hurt!

Modifying those with the group.organization=U'xxxxxxxxxxxxxx' save us 30% resource .

CPU/RAM and HDD have unfortunately still a cost too so as much you can keep your app healty less you will be in the need for those

$ is $ but I prefer to spend on beer vs.HW

You can always use IN statement, instead of joins IN does subqueries,

Good articles but please permit some comments.

Ether if permitted I will not recommend like statement syntax  as shown above

statement like "name like '%XYZ%'" is highly consuming resource and must be avoided as much as possible.

also when possible and for same reason (either if less consuming) this is recommended to use the direct stored value vs. dotted reference.

e.g.

constrains: customer.organization.name not like '%XYZ%'

is more consuming that: customer.organization.name !='xyz'

that itself more consuming than customer.organization =U'xyzxyxzxyzxyzxyzxyz'

you may not notice much but small rivers make oceans

just my 2 cents practice

/J