Hi Marcelo, Happy to help. For your new field, since it is going to be hidden, there is no need to make it read-only, although it probably won't cause any problems if it is, since its value is going to be set using workflow.
Good luck, Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Wednesday, November 11, 2009 11:24 AM To: arslist@ARSLIST.ORG Subject: Re: Active link to check entry in table Lyle, That make sense, thank you for the detailed steps outlined below. I will definitely try what you have suggested. You are correct, the form which keeps the associations is AST:CMDB Associations. Every time an "ASSET" association is made, a record is created here. (Incident associations are kept in HPD:Associations.) Under "Entry 1" is the location where the change ticket information is located: form name, request ID (CHG ID), description, etc. Under Entry 2" is the location where the asset information is kept: form name (AST:BaseElement), request ID, etc. Currently, I have created an AL to set a field value when a user selected Request Type = Configuration Item AND fires when they press "Search" button. The bad thing is that my AL has no way of knowing if the user has added a CI or not. Therefore, your suggestion is more in line with what I am trying to accomplish. To create the temp field (correct me if I am wrong): I just create a character field - hidden (display tab), read only (display tab), input length 15 (database tab), permission public-change (permissions tab). Again, thank you very much for the help! Marcelo -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Tuesday, November 10, 2009 12:09 PM To: arslist@ARSLIST.ORG Subject: Re: Active link to check entry in table Hi Marcelo, When I say "temp" field, I think that's just a carry-over from my programming background (think "temporary variable"). What I mean is that you would store the result in a display-only field whose sole purpose in life is to store temporary results like this. There are probably a number of fields like this put on the form by BMC (things like z1D Char1, etc.), but I would recommend adding your own to ensure that you don't interfere with any OOB workflow. When you create a relationship to a Change record, it creates two records that represent the relationship. For a CI, one of them will be in AST:CMDB Associations. The other will be in something like CHG:Associations (or something similar, I don't currently have Change installed to verify the actual name). In either form, there are two section that store information about one record or the other, Entry 1 and Entry 2. Generally, Entry 1 is what the relationship points 2, and Entry 2 is what the relationship comes from. For example, in the CHG:Associations form, the Request ID under Entry 2 (Request ID02) will be the request ID of the Change Record, and the Request ID under Entry 1 (Request ID01) will point to the other item - in this case, the CI. In the AST:CMDB Associations form, it will be the other way around: Request ID02 will be the CI, and Request ID01 will be the Change record. So, to verify if a relationship has been made between the change and a CI, you simply need to see if there is at least one record in AST:CMDB Associations where 'Request ID01' = the Change ID. To do the test requires 2 active links - one to do the look up, and a second to verify the result. So, you're left with this: 1) Add a new Display Only character field to the Change form and make it hidden but with Public Change permissions. You can simply make it 15 characters long, because all it needs to store is a request ID. 2) Create a new active link with Public permissions that fires on Submit/Modify and performs a set fields action. Note that execution order is important - you want it to fire before other BMC workflow fires in most cases. The set fields action will set fields from AST:CMDB Associations where 'Request ID01' = $Change ID$. (Note that $Change ID$ may not be the correct field name. See what the real name of the field is and use that.) Now, simply set your new display-only field to the value of Request ID01. (It doesn't really matter what you set the field to - all you really care about is that it gets a value if a record is found. Using Request ID01 is just easy.) Set it so that if multiple records match, it uses the first record. If no records match, set the field to NULL. 3) Create a second active link with Public permissions that fires on Submit/Modify and whose execution order is just after your first active link. Since you want to display an error if there is no relationship, you want the active link to fire when your display-only field is $NULL$, which means no record was matched above. So, the Run If qualification is something like this: 'My Display Only Field' = $NULL$. Then, in your If Actions, you can display your error message. Does that make more sense? Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Monday, November 09, 2009 4:06 PM To: arslist@ARSLIST.ORG Subject: Re: Active link to check entry in table Lyle, let me know if I'm missing something. Here are the steps you've suggested Write an AL that fires when I press "relate" button on "CI Relationships Search"(AST:CI Associations Search) form to do a set fields to a hidden field on CHG:Infrastructure Change form. Then I have an AL that reads this field and fires my error based on whether this field is null. I do not know how to make it work with temp fields, if you could, please explain. Thank you, Marcelo -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Monday, November 09, 2009 4:44 PM To: arslist@ARSLIST.ORG Subject: Re: Active link to check entry in table I suspect that the field you are checking is a column in the table which will only have a value if a row has been selected. A better way to do it would probably be to ignore the table field on the form and do a set fields actions from the underlying associations form to a temp field on your change form. If the set fields succeeds, the temp field will have a value which means a CI was related to the change. If no records were matched, then a CI wasn't related, and you can throw up your error. The key, then, is just to get the qualification on the set fields action correct so that you match only CI relationships and not things like relationships to other changes, problems, etc. Does that make sense? I can go into more detail if you'd like. Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Martinez, Marcelo A Sent: Monday, November 09, 2009 3:26 PM To: arslist@ARSLIST.ORG Subject: Active link to check entry in table Hello All, I'm currently trying to put together an active link that will spit out a warning message to change mgmt users to remind them to add a configuration item. I'm currently running ARS7.1 and ITSM 7.0.03 (Inc, Chg, Pbm). I would like the active link to check the Relationships table under change mgmt and if there are no entries for CIs associations, then spit out the warning message. The message should display when the change has been submitted for approval. What I've done is: created an AL that fires on Submit/Modify with the RunIf: ( 'z2TH_Assoc_Association' = $NULL$ ) AND ( 'Change Request Status' >= "Request For Authorization" AND 'Change Request Status' < "Scheduled") Action 1: Message. Type=Warning. Text: don't forget to add a CI!!!! The problem is that the AL fires even if the CI has been associated. Can someone tell me where I can find documentation on creating an AL that checks a table entry? Thanks! Marcelo _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"