17.3 - Create Incident from Process automation with 'OP' - ERROR

[Peter Schmidt]

Hi,
in a migrated German ITSM-Env I cannot
create a new incident ('I') any longer via Process Automation.
Since migration from 17.2 to 17.3 I get the error:

    AHD05914:Status transition from '[creation]' to 'open' cannot be validated

I'm using soap-operator 'createRequest'

Creating requests('R') and Changes is working as before.
Do I have to create an additional incident-transition?

At the moment I only have an incident-transition '' to 'OP'
I cannot find a status corresponding to error's from '[creation]' .

Thanks,
Peter

------------------------------
Senior Technical Consultant
Fujitsu Services
------------------------------

[Brian Mathato]

Hi Peter,

I think you could resolve this by simply setting the Status_Policy_Violations to WARN in the Options Manager. The message will be logged in the stdlog, but should allow the operation (creation of the ticket) to happen at webservices level even though the status transion in question does not exist.


If you want to validate if this is a bug is SDM, then use SOAPUI to try the same thing, directly without ITPAM. If you are still able to reproduce with ITPAM out of the picture, then log a support case for engineering to look further into this.


------------------------------
Kind Regards,
Brian
------------------------------

[Peter Schmidt]

Hi Brian,
thank you first.

Status_Policy_Violations is already set to WARN in the Options Manager.
The complete response looks like this:

<Fault xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode>soapenv:Client</faultcode>
<faultstring>Error setting attr 'status' on object 'cr:1203042' to value 'OP' AHD05914:Statusübergang von '[Erstellung]' zu 'Offen' konnte nicht validiert werden.</faultstring>
<faultactor/>
<detail>
<ErrorMessage>Error setting attr 'status' on object 'cr:1203042' to value 'OP' AHD05914:Statusübergang von '[Erstellung]' zu 'Offen' konnte nicht validiert werden.</ErrorMessage>
<ErrorCode>1003</ErrorCode>
</detail>
</Fault>

I'll check it with soapui in the next step and a little process without complicated behaviour.

Thanks and regards,
Peter

------------------------------
Senior Technical Consultant
Fujitsu Services
------------------------------

[Brian Mathato]

You might also want to test the same using the 'createObject()' to check if this is perhaps an issue with the 'createRequest()' or generic to any attempt to create I/R/P regardless of the method being used with webservices... 

------------------------------
Kind Regards,
Brian
------------------------------

[Peter Schmidt]

Hi Brian,
I think I found it. 
In the past, all referenced attributes had to be filled with the persid of the attribute. Hm, crt was set with crt:182 what is the pid of 'I'.
As long as I do not add category to my parameterlist it works ... nice ...

But as soon as I add category to my attrVals I get the documented error.
If I set the pair of type to string 'I' it works ...

And this is reproducable with SoapUI also.

Next step is to modify process and test it. I'll keep you informed.

Regards,
Peter

------------------------------
Senior Technical Consultant
Fujitsu Services
------------------------------

[Peter Schmidt]

Hi Brian,
seems to work now.

type must be set to 'I' not to the pid of 'I'

Why this error comes since 17.3 --- I don't know. Till 17.1 it worked also with 'I's persid. Hm ...

Thanks and regards,
Peter

------------------------------
Senior Technical Consultant
Fujitsu Services
------------------------------

[Brian Mathato]

Hi Peter,

Glad to hear you managed to trace the root cause of the error, despite the error message being somewhat misleading. It almost let us go off on a tanget.

------------------------------
Kind Regards,
Brian
------------------------------

[Michael Mueller]

Hi Brian.
In my understanding this is an error, which should be fixed.
As Peter already mentioned , to set SREL attributes , documentation is saying : use the persistent_id of the referenced record. 
This is valid and works for all other SREL attributes for all other factories, as far as I am aware.
It should work the same for the type attribute in factory cr as well !
Yes, I am aware of the exception in method createTicket for its problem_type xml tag value, but this exception is well documented.
What do you think?
Regards
..........Michael

------------------------------
Principal Services Consultant
HCL Enterprise Studio
Germany
------------------------------

[Michael Mueller]

Hi Brian.
Add-On:
I just found the following in 17.3 documentation: well, this text passage is already in the docs for 14.1
-------------

To set an SREL attribute, such as with updateObject(), you can pass the persistent id of the object to which you want to point. In order to simplify this action, this release of CA SDM has been enhanced so that the REL_ATTR (foreign key) value may be used to set an SREL.

For example, as the REL_ATTR of the crt object (Request Type) is its code attribute, the values "R", "I" and "P" can be used to set the type attribute of a cr object to specify that the ticket is a Request, Incident or Problem. The cr's type attribute can be set to "R" instead of "crt:180", "I" instead of "crt:182" and "P" instead of "crt:181".
------------

You can either use the persistent_id or the REL_ATTR value.
So, both should work, in my understanding.
Regards
..........Michael

​

------------------------------
Principal Services Consultant
HCL Enterprise Studio
Germany
------------------------------

[Peter Schmidt]

Hi Michael and Brian,

both is working as long as I don't set SREL of Category.

Mystic but this behavior can be reproduced with SoapUI.

crt-pid  + category-pid + other attributes --> Error
crt-'I'    + category-pid + other attributes --> incident succesful created
crt-pid  + other attributes                         --> incident succesful created
crt-'I'    + other attributes                         --> incident succesful created

 

Regards,

Peter

------------------------------
Senior Technical Consultant
Fujitsu Services
------------------------------

[Brian Mathato]

@Michael Mueller​ - Please go-ahead to log a support case and a defect will be logged to address the bug in question


------------------------------
Kind Regards,
Brian
------------------------------

[Michael Mueller]

@Peter Schmidt ​​?

------------------------------
Principal Services Consultant
HCL Enterprise Studio
Germany
------------------------------

[Peter Schmidt]

Hi @Michael Mueller

You tagged the wrong person. ​ Apperently we're several people with the same name.

Cheers.

[Peter Schmidt]

Nice,
I'm not the onlyone ;-)

Yes Michael, Brian, I think we should open a CASE for it, ...., but there's less time ...
So ...

Thanks and regards,
Peter

------------------------------
Senior Technical Consultant
Fujitsu Services
------------------------------

[Michael Mueller]

My expectation: Broadcom is aware of this issue, Broadcom should handle it;)
Sorry Brian.

------------------------------
Principal Services Consultant
HCL Enterprise Studio
Germany
------------------------------

[David Cader]

We are having this same problem. Are there any plans to fix this and if so what is the timeframe?

[Michael Mueller]

Hi David.
I suggest to open a support issue.
Otherwise, I assume, this will never be fixed.
And if it goes bad, support will deny to handle this, as there seems to be a workaround.
Regards

....Michael

------------------------------
Principal Services Consultant
HCL Enterprise Studio
Germany
------------------------------