Control-M Integration - FORM_LOOKUP_ARRAY - How to trigger 2 forms

Not Yet Reviewed

In the https://github.com/xmatters/xm-labs-control-m-9 it shows 1.6.1 Configuring the FORM_LOOKUP_ARRAY.  We did that and it worked fine until I decided we needed another form.  I would like to trigger 2 forms if the job status is ENDED NOT OK.  Here is how I configured the FORM_LOOKUP_ARRAY:

{

               "JOB ENDED NOT OK": "/api/integration/1/functions/8ed95d4a-2a58-4b29-995c-4bffa3922d34/triggers?apiKey=6612e456-4e68-4959-ba25-4bcad113fdd4",

               "JOB RUNS TOO LONG": "/api/integration/1/functions/02d520cf-e1b7-4d06-971a-c3a0dc9aff56/triggers?apiKey=9f081ac0-8edb-4a19-ac4e-48d23ab304e7",

               "JOB COMPLETED TOO FAST": "/api/integration/1/functions/c611b2c5-40f7-44ae-b408-266205a6c2cf/triggers?apiKey=f44678e7-0c1d-49e7-92a7-59c423d9203c",

               "ENDED NOT OK": "/api/integration/1/functions/8ed95d4a-2a58-4b29-995c-4bffa3922d34/triggers?apiKey=6612e456-4e68-4959-ba25-4bcad113fdd4",

               "ENDED NOT OK": "/api/integration/1/functions/3152d139-d3f6-48a8-a3a7-47369f1af386/triggers?apiKey=ed2ba950-2ce0-4827-bdde-45392b859419",

               "RUNS TOO LONG": "/api/integration/1/functions/02d520cf-e1b7-4d06-971a-c3a0dc9aff56/triggers?apiKey=9f081ac0-8edb-4a19-ac4e-48d23ab304e7",

               "COMPLETED TOO FAST": "/api/integration/1/functions/c611b2c5-40f7-44ae-b408-266205a6c2cf/triggers?apiKey=971dea9e-0a10-469c-8bdd-bbf1bf9cf917",

               "WAIT HOST": "/api/integration/1/functions/8ed95d4a-2a58-4b29-995c-4bffa3922d34/triggers?apiKey=6612e456-4e68-4959-ba25-4bcad113fdd4"

}

I am guessing it’s not triggering both forms if ENDED NOT OK because I didn’t code it right.  The form I added gets triggered but the original form does not get triggered.

0

Comments

9 comments
Date Votes

Please sign in to leave a comment.

  • Hi Julia,

    Good question! These look like integration endpoints, not form ones so I am thinking maybe instead of invoking one of these 2 times, invoke it the one time and on the xMatters side we just add more to the code to do what you are looking for. So it would still call /api/integration/1/functions/8ed95d4a-2a58-4b29-995c-4bffa3922d34/triggers?apiKey=6612e456-4e68-4959-ba25-4bcad113fdd4 but that in turn runs a script on the xMatters side to do some tasks and we can maybe build that out to do more of what you are looking for (whether it's message out 2 forms instead of one or what have you)

    Do you think that would be more doable? I would have to look at what each of these does to know for sure and can respond back once I had a chance to do that but checking if one integration to do more things would make sense for this scenario.

    Happy Thursday!

    0
  • Well, here is the deal, we have two servers set up in Control-M, one for the mainframe and one for distributed tasks. Currently we have only mainframe jobs running in Control-M but we are testing all sides. We have xMatters working with Control-M for the most part. This issue started when we figured out that some commands identified in the xMatters github instructions do not work for the mainframe.  See https://support.xmatters.com/hc/en-us/community/posts/360072688512-How-to-add-an-xMatters-shout-destination-on-mainframe-table and https://support.xmatters.com/hc/en-us/requests/158214.

    The triggers are emails sent to various recipients after a job ends not ok (or other conditions but I'm not concerned about the other conditions).  There are links at the bottom of the emails that a user can click on to make Control-M do something to a job.  These links do not work for mainframe jobs.  Since they do not work, I wanted to remove the links but only for jobs coming from the mainframe server.  I thought removing them in subscriptions would work, but I see no way of doing that.  So I decided to create a new form, have the End Not OK job status trigger both email forms, and then use subscriptions to identify which server the job came from.

    Also, I found out last week that we have a few stakeholders that will need to be notified when a job ends not ok.  So I will need to create another form with no links, no matter where the job came from.

    So the goal is one job status...Ended Not OK....and three possible emails, one with all links, one with no Control-M links, and one with no links.

     

    0
  • I'd absolutely want to do this with Flow Designer Julia.    Though the control-m integration pre-dates flow designer I think that almost all of the logic is done on the agent, so there's really nothing to stop you creating a flow trigger in xMatters that can accept the call the Agent is making (instead of the integration) and then do some logic in Flow Designer.  It would be very possible to use a switch in FD to look at some aspect(s) of the event packet and then send it to different forms in the workflow depending on what responses you wanted.

    0
  • I need help with how to do this.  I have been studying the guides (how to convert an inbound integration to flow designer) but do not understand and do not want to mess up what has already been created and works.  In the Abend flow, there is one trigger on the canvas called "Trigger Abend Form".  Editing the trigger, there is no Script tab to look at a script.  The FORM_LOOKUP_ARRAY that I showed you in my first post is in the Edit Constants tab.  That looks like part of a script.  Isn't there a way to code that section so both URLs are triggered if the status is "ENDED NOT OK"?

    If that cannot be done and I need to convert to flow designer, I haven't been able to figure that out.  The guides are not helping me much.  I know there is a controlm_server property that I should be able to use somewhere to identify which email form to use.

     

    0
  • I'll reach out via email. This might get a little too complicated in the forum. 

    0
  • I got on the call with Julia. We added an if block to the inbound Request from IA integration to look for the job_status == "ENDED NOT OK". The if block pulls out a new entry called "MF ENDED NOT OK" from the FORM_LOOKUP_ARRAY constant and sends another event. 

    0
  • It works good for the most part.  I have 3 issues now:

    The Authenticating User:  We changed it to Control-M Integration and the URL in the FORM_LOOKUP_ARRAY.  For some reason it stopped working or we changed it after we tested.  When I went into the form in the Integration Builder, it was switched back to my user ID.  I tried to change it again.  There is a Save button just above How to trigger the integration but it's grayed out.  When I changed the URL to my user ID URL, it worked again.

    Distributed Alerts:  We only ran a mainframe test job which worked beautifully (and still does with my userid).  We should have run my distributed test job. I changed the subscription form to use only the Abend form but it triggered both the Abend and the Mainframe Abend forms.  I had to change that URL to my authenticating userid in order to get any alerts.  But now I get 4 alerts in xMatters (the Alerts bell at the top shows 3) and 3 emails with differences as follows:

    Alert 1 - Control-M Server is SLCISCTRLM - Contains all links

    Alert 2 - Control-M Server is slcisctrlm - Contains 3 links

    Alert 3 - Control-M Server is slcisctrlm - Contains all links

    Alert 4 - Control-M Server is slcisctrlm - Contains all links (no difference from Alert 3)

    As for the emails, I received Alerts 1, 2, and 3.

    In my distributed subscription, I used SLCISCTRLM (all caps) as the value for controlm_server

    The distributed alerts issue is not as urgent as the mainframe issue was since we don't have Control-M running any distributed jobs, yet.  But I am afraid of what is going to happen when I add another form for stake holders.

    Start and End Times:  I noticed that the Start Time and End Time in the form email is way off.  In Control-M, the start time for my last test job is 10/15/2020 7:21:17 AM. The Start Time in the alert is showing Thu, Oct 15th, 2020 1:21:17 AM MDT.  I noticed this before in other alert emails but haven't thought about needing to fix it until now.

    0
  • Well, I feel like an idiot.  I figured out the problem with the distributed alerts.  I had set up a Control-M shout on-do action in the job and forgot it was still there.  The shout technique works for distributed jobs but does not work for mainframe jobs.  I set up the SNMP Trap technique because of this.  Anyway, I removed the shout and now the alert email works like I want it to.

    I still have the authenticating user issue and the start/end times issue.

    I am going to go ahead and add another form for stakeholders.  I believe it will work.

    Thanks again for your excellent help.

    0
  • Great, thanks for sharing the solution Julia! The community will no doubt benefit from this knowledge someday 😊
    Happy Thursday!

    0

Didn't find what you were looking for?

New post