Open alescernivec opened 2 years ago
I'd like to discuss the design of this in a more holistic sense and not cisco intersight specific. We have had requests in the past for ServiceNow integration across all parts of the product, and at Red Hat they had ServiceNow integration via Automate which may be able to be reused [ref]. Since ServiceNow is not an integral part of cisco intersight itself, it should not be tightly coupled to the cisco intersight plugin. @agrare Thoughts?
I fully agree with this and we are still examining the proposed idea for the integration. Thanks for the ref! Actually, we have already done some experimenting with this way of integration with ServiceNow.
We've done some advances on this matter. We've managed to create a package based on the existing integration scripts (what has been referenced above) through Automation, and also we've managed to create related dialogs and a ServiceNow button in the physical provider. While simulating these (through "Simulate" option), everything looks OK. But when triggering the action from the physical provider via the button, we get this error (from development.log
):
...
[----] F, [2022-11-10T12:03:00.910892 #14671:5a2a8] FATAL -- development: Error caught: [ActionController::UrlGenerationError] No route matches {:action=>"dialog_load", :controller=>"ems_physical_infra", :dialog_locals=>{:resource_action_id=>183, :target_id=>2, :target_type=>"ext_management_system", :real_target_type=>"ExtManagementSystem", :dialog_id=>3, :api_submit_endpoint=>"/api/providers/2", :api_action=>"Create Incident", :finish_submit_endpoint=>"/ems_infra", :cancel_endpoint=>"/ems_infra", :open_url=>false}, :id=>"2"}
/usr/share/rvm/gems/ruby-3.0.0/gems/actionpack-6.1.7/lib/action_dispatch/journey/formatter.rb:44:in `path'
/usr/share/rvm/gems/ruby-3.0.0/gems/actionpack-6.1.7/lib/action_dispatch/routing/route_set.rb:823:in `url_for'
/usr/share/rvm/gems/ruby-3.0.0/gems/actionpack-6.1.7/lib/action_dispatch/routing/url_for.rb:181:in `full_url_for'
/usr/share/rvm/gems/ruby-3.0.0/gems/actionpack-6.1.7/lib/action_dispatch/routing/url_for.rb:171:in `url_for'
/usr/share/rvm/gems/ruby-3.0.0/gems/actionview-6.1.7/lib/action_view/routing_url_for.rb:89:in `url_for'
/usr/share/rvm/gems/ruby-3.0.0/gems/jquery-rjs-0.1.1.3/lib/action_view/helpers/jquery_helper.rb:457:in `redirect_to'
/usr/share/rvm/gems/ruby-3.0.0/bundler/gems/manageiq-ui-classic-2b214a9671ad/app/helpers/application_helper.rb:968:in `block in javascript_redirect'
/usr/share/rvm/gems/ruby-3.0.0/gems/jquery-rjs-0.1.1.3/lib/action_view/helpers/jquery_helper.rb:154:in `instance_exec'
/usr/share/rvm/gems/ruby-3.0.0/gems/jquery-rjs-0.1.1.3/lib/action_view/helpers/jquery_helper.rb:154:in `block in initialize'
/usr/share/rvm/gems/ruby-3.0.0/gems/actionview-6.1.7/lib/action_view/helpers/capture_helper.rb:209:in `with_output_buffer'
@Fryguy perhaps you have some pointers on how to tackle this issue? Thanks in advance!
@Fryguy hi, we check with our team how we solve this. my suggestion is to add the button of service now in all the toolbars in the system throw the code and not in the automation engine. when a user will click to create a new ticket he will enter the credentials of the service now instance for the first time. the credentials will be stored in the authentications table in the manageiq and will be attached to separate providers (autosde, cisco_intersight, ext..) next will redirect to create form page of the ticket and after submitting of the form a rest call will be done to create this ticket.
This sounds like the opposite of what I was saying earlier where I was preferring a common ServiceNow implementation (unless I'm misunderstanding?)
@Fryguy it will be the same implementation for each page but it will give the user the ability to connect each provider to different service now instance.
Or you prefer one configuration for the service now connection?
Yeah I think we'd want one service now connection, perhaps per tenant?
Where would you store all of this ServiceNow code if not automate? Would it be directly in core?
ok so we will start with one service now connection. I think it needs to be in the core. the question is if we want to store this tickets values in the manageiq db or if we will create the rest call to the service now instance and end the process without saving the data?
@eilam20 We've tackled the issue using Automate engine (mentioned above). Maybe this can help: Dialogs - https://github.com/xlab-si/ServiceNow_Dialogs and CMDB part - https://github.com/xlab-si/ServiceNow_CMDB . With this you can embed the dialog for ServiceNow in any provider.
@Fryguy hi, I created a form to post the values to the service now API. Do we want to use the miq API and add a new endpoint and module called service now?
hi all - sorry, I've been swamped lately and haven't been able to review any of this. If possible, let's get a call together so I can go back and forth with questions...I think we can quickly come to an architecture we agree on (I'm pretty sure it's close as is) - please also include @agrare.
Hi, I wrote down some points and questions about the pre-development process. I am also available next week to talk about things.
In the connect service now instance form the user needs to enter the following: domain username password
Question: set the table name for creating the ticket or set it in the create ticket form?
when the user submits the form a new record will be added to the authentications table with the credentials for this domain.
Now, when the user clicks on create new ticket he will need to add the ticket details that will be sent to the service now API. the service now credentials will be taken from the authentications table and will be sent to the service now API.
Questions:
Cisco Intersight ManageIQ Provider should support "incident" and "service requirement" types of Service Now tickets.
There are additional requirements that need to be taken into account:
We foresee different use cases: