Manual Application Services - Service Mapping View

[Alec Hanson]

I am trying to get my head around with the new "Application Service" Physical alignment in the CMDB in Paris (v3.0) which is:

I understand that Application Service is now (cmdb_ci_service_auto) and there are child Classes for a variety of  Population Methods.

This states that Manual Application Services are stored in cmdb_ci_service_discovered as previous but now called Mapped Application Service

However if I select the Manual Population Method I have to provide a CI at that point in time, and as this is in effect driving a discovery/service mapping model creates a "Manual Endpoint" CI.

A number of clients are either managing manual data (due to the small size) or using external discovery tools and the end user might not know any CIs at time of creation or it might be a SaaS application without an Infrastructure CI. If you do not enter a manual CI then the Application Service is created as a cmdb_ci_service_auto.

Questions:

1. What does the Manual Endpoint provide within the scope of a 'Manual' Application Service?

2. Is there anyway of creating a Manual Application Service now in Paris without an infrastructure CI within the cmdb_ci_service_discovered class?

3. Does this work with SaaS application services - a very common thing these days?

Any thoughts welcome.

[jimmillet]

I have a related question. I am working with a small client, they are NOT using Service Mapping or Discovery or SN Event Management. This instance has been in place since 2014, so they loaded all their business applications (aka business services) into cmdb_ci_appl table. I am trying to move them to "crawl" stage of CSDM adoption and I am trying to move these CI's to the Application Service table. Down the road they want to manually map the infrastructure to these application service CI's. The client is at Paris. First I thought the table name was "cmdb_ci_service_auto", but now when I look at the docs I see a table named "cmdb_ci_service_discovered". So now I am confused as to which table to move these. In one of these community posts, it was mentioned that "cmdb_ci_service_auto" is just a dummy class and not meant to be populated. In the CSDM 3.0 material it mentions "cmdb_ci_service_discovered", so I tried that. But when I tried to change the class name of one of the existing CI's in cmdb_ci_appl class to "cmdb_ci_service_discovered, I got an error "There are no entry points for service, changing status to Non-Operational". I need these to be operational , so when I changed the status to operational status, I get error message saying" Empty service cannot be operational. Add some entry points".  I am not ready to start any mapping, I just wanted to start the first step of moving the CI's out of cmdb_ci_appl class. Is it OK to move the CI's to "cmdb_ci_service_auto", I got no error messages when I did that.

Sorry for long post.......hoping someone can provide some guidance.

[Sebastien7]

Hi,

Could you test this now with an instance Quebec Patch 3 please ? 

I've see some differences since this version and i could create / migrate CI in this classes without Entry point and they still operational.

B.R.

[JD37]

I have the same issue, we have a very simple ITSM solution and are not using Service Mapping, or Discovery, and no Event Management.

Following an upgrade from Orlando to Quebec (Patch 3) all our CIs with a Class of Application Service have been updated to a CI Class of Mapped Application Service.

When I was asked to update the Operational status from Non-operational to Operational on one of these I was presented with the "entry points" error. I'm a bit out of my depth here and have limited knowledge of CSDM which is where this seems to lead.

I'm guessing we need to re-evaluate what we have and align it with the CSDM? Or can this be sidelined as a future task and we can continue working as we were before with some minor adjustments - any help is appreciated.

[Barry Kant]

Hi all,

the best way to understand what happens (in my opinion) is this way:

1 - Create a New Application Service via the CSDM menu:

2 - Fill in the mandatory fields. Don't relate to underpinning Services or CIs:

Don't relate to underpinning Services or CIs:   

Save the record. Validate in the cmdb_ci_service.LIST view, add the class attribute and you will see that the class is: cmdb_ci_service_auto.

Now relate it to underpinning infrastructure:

I choose Manual relation to a windows server. Save the record.
now you see that the class is changed from cmdb_ci_service_auto to cmdb_ci_service_discovered.

So my assumption is that the application services have a downstream relation, and that that is the reason to change the class. If you don't have relation you might change it back to the cmdb_ci_service_auto. 

Can you verify this from the CSDM menu?

Best regards,
Barry