CA Service Management

Hi all, 

I am having an issue in Catalog that is driving me crazy....any help would be greatly appreciated. 

I have a service offering that is linked to a group that is linked to a form.

My events rules and actions are like this

This external_id is indeed the external_id of the Service Option Group (SOG). 

Now when I go to my Service Offering and hit submit, it shows my rule is indeed working, but I only want 1 process to be kicked off in ITPAM and not 8!

I then go back to my rules and make the rule something junk

external_id = xxxx

When I run another request in catalog, nothing kicks off to ITPAM as expected. 

I change the rule again from 

external_id=xxxx 

back to

external_id = 'MyBounceServiceDesk'

In theory.....one would say that nothing has been changed?

However, when I submit the form again in Catalog, there are still no processes. 

In my frustration I delete the entire rule and start again. 

I create the rule again with event filter : external_id = 'MyBounceServiceDesk'. 

Now I am back to seeing the 8 processes instead of just 1.

Can anyone please advise if they have seen such strange behavior before or if I am missing something entirely?

Hi James,

When requests are created/modified (i.e. submitted, approved, rejected, fulfilled, etc) there are a number of events that are fired, even for the same event type (i.e. Request/SubscriptionItem Change). This is why the majority of OOTB rules include status old and new ranges as well as rate_item_col=0, similar to the following under Request/Subscription Item Change, so the action is only invoked by the event that has the status transition from not submitted range (100-199) to submitted (200) status:

When Status is Submitted and Approval Process is driven by Workflow

status < 400 AND status >= 200 AND status_old < 200 AND status_old >= 100 AND rate_item_col = 0 AND approval_process = 2

When Status is Pending Approval

Rule with filter that fires when status changed to Pending Approval. Depending on discrete configuration this rule will be fired once per service or once per service option.

status=400 AND status_old <> 400 AND rate_item_col = 0

When Status is Pending Fulfillment 

status_old >= 800 AND status_old <= 999 AND status = 1000 AND rate_item_col = 0 AND approval_process = 2

As noted in the description of the pending approval rule, discrete configuration (Catalog > Configuration > Request Management Configuration > Allow Discrete Handling of Service Options After) will impact the behavior/number of times the rule/action is invoked (i.e. once per service vs once per service option in the request):

Discrete Request Life Cycle Parameters - CA Service Management - 14.1 - CA Technologies Documentation 

I could suggest the following to help identify the events and what parameters may be necessary in your rule event filter:

1) Create a rule under the event you are using and leave the filter empty
2) Create an email action and pass some helpful parameters (by selecting the triangle icon) in the subject similar to the following:

    Request $request_id$ Status: $status$ Old status: $status_old$ rate_item_col: $rate_item_col$ external_id: $external_id$

3) In the body you can include $all$ which will include the data for all of the event parameters or any other relevant parameter
4) Carry out the specific Catalog functionality and analyze the details/differences between events/emails

Also, not all events are related specifically to status/status change. As an example, for Request/Subscription Item Change, I believe the events are more so invoked per service option element (i.e. Name, Description, Form, etc) in the service option definition. So if there are 3 service option elements in the requested service option, you would see 3 emails each time the request/form/status is changed if you use an empty filter as mentioned in step 1 above. This is why the OOTB filters under Request/Subscription Item Change include rate_item_col=0 in addition to the status/status_old ranges.

As for the PAM process instance failing to invoke after modifying the rule/action, I have seen this addressed by a recycle of the Catalog service, not sure if you tried before deleting/recreating.

Thanks,
Jason

Thanks for the helpful reply Jason. 

I am happy that the PAM process is failing (that's a separate issue), I'm more concerned with the transactions that are not being sent to PAM. 

Let me give you some more background regarding my troubles. 

My event filter originally was similar to your suggestions

approval_process = 0 AND rate_item_col = 0 AND status = 1000 AND external_id = 'MyBounceServiceDesk'

which i then made less strict 

external_id = 'MyBounceServiceDesk'

All our other processes have this exact some rule with obviously external_id being different.

So my rule was based on already existing and working processes.  

It is only recently that I have experienced this issue. 

I then tried to add a few more rule.....make it a bit stricter

external_id = 'MyBounceServiceDesk' and approval_process = 0

After testing again, I had the same issue.

As per my original query, I then realized that deleting the rule entirely and creating again was the only way to get the PAM process to kick off again. 

I lost you a little bit regarding the email rule to add. However I find this could be very useful. 

As per below, are you saying that an email will be sent when a request is submitted?

If so, do I simply put my email address in the To field?

Are you also saying I can put in any parameters I wish in the remaining fields?

e.g: $status_old$ rate_item_col: $rate_item_col$, etc?

Almost correct jwood1, you can add your email address in the corresponding field. However, it does not means that the email will be sent. As Jason said, if you want to understand what happens when you walk a request throughout it's lifecycle, you can use a blank rule, send $all$ as the Message and compare email every steps on the way!

As per Jason's suggestion, you may really want to consider adding status_old to your filter. This way you ensure that you will only "catch" status transition. (I assume that's what you want). I've had the same issue, pam workflows being launched 5 times instead of one.

Regards,

Pier

And yes, you can add other parameters in the Subject or in the message. But with $all$, it's One parameter to rule them all. Okay i'm out.

Hi jwood1 - Did POssq's response help answer your question? If so please mark as Correct Answer. Thanks!