SM7.00 I.E.

348

SM7.00 I.E.

349

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

350

Presentation Title

351

Presentation Title

SOAP ServerAPI Server- special case of the SOAP Server- no port redirect single threaded- 1 port per user (dedicated instance per app) consults the Doc Eng to learn what to expose in WSDL Document Engine- abstraction of RAD Apps- essentially RAD with Tailoring

WSDL- compile time binding

352

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

353

Presentation Title

Before diving into concepts and terminology, I thought it would be a good idea to try to convey something about the purpose and the value of web services. This graphic is my perspective on that. Web services is the latest technology for application integration. It is superior to earlier technologies because: It is standardized by organizations like W3C, WS-I, etc. It is based on widely available non-proprietary web technology, such as HTTP, XML, etc. Vendor agnostic, not controlled by any single company As long as everybody plays by the rules, you can mix and match WS tools and implementations Tools and Web Service implementations interoperate with no vendor communication or cooperation required, for example: Applications developed using Microsoft Visual Studio .NET work with Service Manager 7 Applications developed using Axis work with Service Manager 7 Applications developed using Service Manager 7 work with all 3rd party web services we have so far encountered

354

Presentation Title

WSDL is a W3C (World-wide Web Consortium) standard for describing web services. A WSDL file is an XML document. A WSDL file describes the API calls (if you will) of the web service. In WS terms, these are called SOAP operations, or methods as they are often called. The WSDL also describes the inputs and outputs of a web service in terms of XML messages. And it gives information about the location of the web service, typically an HTTP URL. Typically, the programmer doesnt read WSDL directly, one uses some sort of SOAPenabled application development toolkit to process WSDL into code, as in the screen shot we looked at a moment ago. The toolkit you choose is up to you. So instead of needing a vendor SDK, you just pick some toolkit of your choice for the platform you want your SOAP client application to run on. Ive listed some popular web services tools that developers use to create applications with. The last one, wsdl2js, is a HP-provided utility first developed in ServiceCenter 6.1. Developing a SOAP client application to consume a web service is basically a two-step process. First you generate code from the WSDL, then you fill in the blanks so-to-speak to make the generated code do something useful. This can be a pretty simple process as well see in a moment. Service Manager 7 will ship with Java samples for Axis, C# samples for .NET, and some Javascript samples within the Service Manager 7 script library.

355

Presentation Title

With web services, we tend not to use the terms client and server, but they are applicable. If we say application XYZ exposes a web service (or web services) which we mean that application XYZ can act as a SOAP server which will respond to requests from a SOAP client. We also like to speak of an application as consuming a web service, and this just means that the application is a client of that web service. SC 6.0 can serve web services, without the customer having to write any code, and SC 6.1 improves substantially on this process, but the Service Manager application developer in 6.0 has no way to invoke a web service in some other enterprise application, such as Peoplesoft, or SAP or whatever, or a homegrown web service, which a lot of customers are starting to build, or at least plan for. Now in SM 7, this can be done, using Javascript, and a new tool called WSDL2JS, which well see a demo of in a moment. The acronym RPC stands for Remote Procedure Call. By RPC programming model we mean that from the viewpoint of the programmer, invoking a web service is a lot like RPC. Well see a live example of this in a moment.

Instructor notes
[Copy and paste this text box on notes pages for all slides]

356

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

357

Presentation Title

So, SM 7 has the ability to consume web services from Service Manager 7 JavaScript applications, but there are also major improvements to the way Service Manager publishes web services in 7. First and foremost, Service Manager 7 exposes its web services in a way that is SERVICE oriented as opposed to file-oriented. The older approach is now deprecated. The new API uses ITIL terminology, not legacy ServiceCenter terminology. In SC 6.0, you had to know that to create an incident, you had to manipulate the probsummary file. Specifically, you had to do a probsummaryAdd operation on it. In SM7, this requirement to know historic ServiceCenter terminology goes away. SM7 exposes an IncidentManagement service, which describes an object called an Incident, and defines a set of operations like CreateIncident, UpdateIncident, ResolveIncident, and CloseIncident. And the fields contained in an Incident object have rational names, rather than ambiguous or historic names. We use IncidentID rather than number for example. Well look at how this renaming or aliasing works later. And we also are excluding most of the fields in probsummary from the new Incident object. Only about 10% or less of the fields in probsummary are needed for most applications. Frankly, theres a lot of historic stuff that has accumulated in probsummary over the years due to the inability to delete fields from files in ServiceCenter due to legacy requirements. In SM7, we no longer publish these old fields, via an exclusion facility well look at later. Another important aspect of the WSDL in SM7 is that it groups all the files you need together into a service. In 6.0, if you wanted to create a SOAP application to do change management related things, you had to not only know about cm3r and cm3t, but you had to make separate WSDL requests for those files and combine the resulting generated code into one project. In SM7, this is done automatically. All of this grouping, aliasing, and exclusion functionality can be thought of as an abstraction layer that protects customer SOAP applications from changes in the low-level Service Manager schema. If we decide to do away with the file known as probsummary in some future applications release, a SOAP client which manipulates Incidents will still work.

358

Presentation Title

So, SC 6.1 has the ability to consume web services from Service Manager 7.1 Javascript applications, but there are also major improvements to the way Service Manager publishes web services in 6.1 First and foremost, Service Manager 7.1 exposes its web services in a way that is SERVICE oriented as opposed to file-oriented which is the way it was done in 6.0. The older approach is now deprecated. A 6.0 application will still work, but we recommend that the new WSDL be used for all applications going forward. The new API uses ITIL terminology, not legacy Service Manager terminology. In SC 6.0, you had to know that to create an incident, you had to manipulate the probsummary file. Specifically, you had to do a probsummaryAdd operation on it. In 6.1, this requirement to know historic Service Manager terminology goes away. SC 6.1 exposes an IncidentManagement service, which describes an object called an Incident, and defines a set of operations like CreateIncident, UpdateIncident, ResolveIncident, and CloseIncident. And the fields contained in an Incident object have rational names, rather than ambiguous or historic names. We use IncidentID rather than number for example. Well look at how this renaming or aliasing works later. And we also are excluding most of the fields in probsummary from the new Incident object. Only about 10% or less of the fields in probsummary are needed for most applications. Frankly, theres a lot of historic stuff that has accumulated in probsummary over the years due to the inability to delete fields from files in Service Manager. In 6.1, we no longer publish these old fields, via an exclusion facility well look at later. Another important aspect of the new WSDL in 6.1 is that it groups all the files you need together into a service. In 6.0, if you wanted to create a SOAP application to do change management related things, you had to not only know about cm3r and cm3t, but you had to make separate WSDL requests for those files and combine the resulting generated code into one project. In 6.1, this is done automatically. All of this grouping, aliasing, and exclusion functionality can be thought of as an abstraction layer that protects customer SOAP applications from changes in the low-level Service Manager schema. If we decide to do away with the file known as probsummary in some future applications release, a SOAP client which manipulates Incidents will still work.

359

Presentation Title

So, SM 7 has the ability to consume web services from Service Manager 7 JavaScript applications, but there are also major improvements to the way Service Manager publishes web services. First and foremost, Service Manager 7 exposes its web services in a way that is SERVICE oriented as opposed to file-oriented which is the way it was done in 6.0. The older approach is now deprecated. A 6.0 application will still work, but we recommend that the new WSDL be used for all applications going forward. The new API uses ITIL terminology, not legacy Service Manager terminology. In SC 6.0, you had to know that to create an incident, you had to manipulate the probsummary file. Specifically, you had to do a probsummaryAdd operation on it. In 6.1, this requirement to know historic Service Manager terminology goes away. SC 6.1 exposes an IncidentManagement service, which describes an object called an Incident, and defines a set of operations like CreateIncident, UpdateIncident, ResolveIncident, and CloseIncident. And the fields contained in an Incident object have rational names, rather than ambiguous or historic names. We use IncidentID rather than number for example. Well look at how this renaming or aliasing works later. And we also are excluding most of the fields in probsummary from the new Incident object. Only about 10% or less of the fields in probsummary are needed for most applications. Frankly, theres a lot of historic stuff that has accumulated in probsummary over the years due to the inability to delete fields from files in Service Manager. In 6.1, we no longer publish these old fields, via an exclusion facility well look at later. Another important aspect of the new WSDL in 6.1 is that it groups all the files you need together into a service. In 6.0, if you wanted to create a SOAP application to do change management related things, you had to not only know about cm3r and cm3t, but you had to make separate WSDL requests for those files and combine the resulting generated code into one project. In 6.1, this is done automatically. All of this grouping, aliasing, and exclusion functionality can be thought of as an abstraction layer that protects customer SOAP applications from changes in the low-level Service Manager schema. If we decide to do away with the file known as probsummary in some future applications release, a SOAP client which manipulates Incidents will still work.

360

Presentation Title

So, SC 6.1 has the ability to consume web services from Service Manager 7.1 Javascript applications, but there are also major improvements to the way Service Manager publishes web services in 6.1 First and foremost, Service Manager 7.1 exposes its web services in a way that is SERVICE oriented as opposed to file-oriented which is the way it was done in 6.0. The older approach is now deprecated. A 6.0 application will still work, but we recommend that the new WSDL be used for all applications going forward. The new API uses ITIL terminology, not legacy Service Manager terminology. In SC 6.0, you had to know that to create an incident, you had to manipulate the probsummary file. Specifically, you had to do a probsummaryAdd operation on it. In 6.1, this requirement to know historic Service Manager terminology goes away. SC 6.1 exposes an IncidentManagement service, which describes an object called an Incident, and defines a set of operations like CreateIncident, UpdateIncident, ResolveIncident, and CloseIncident. And the fields contained in an Incident object have rational names, rather than ambiguous or historic names. We use IncidentID rather than number for example. Well look at how this renaming or aliasing works later. And we also are excluding most of the fields in probsummary from the new Incident object. Only about 10% or less of the fields in probsummary are needed for most applications. Frankly, theres a lot of historic stuff that has accumulated in probsummary over the years due to the inability to delete fields from files in Service Manager. In 6.1, we no longer publish these old fields, via an exclusion facility well look at later. Another important aspect of the new WSDL in 6.1 is that it groups all the files you need together into a service. In 6.0, if you wanted to create a SOAP application to do change management related things, you had to not only know about cm3r and cm3t, but you had to make separate WSDL requests for those files and combine the resulting generated code into one project. In 6.1, this is done automatically. All of this grouping, aliasing, and exclusion functionality can be thought of as an abstraction layer that protects customer SOAP applications from changes in the low-level Service Manager schema. If we decide to do away with the file known as probsummary in some future applications release, a SOAP client which manipulates Incidents will still work.

361

Presentation Title

362

Presentation Title

So, SC 6.1 has the ability to consume web services from Service Manager 7.1 Javascript applications, but there are also major improvements to the way Service Manager publishes web services in 6.1 First and foremost, Service Manager 7.1 exposes its web services in a way that is SERVICE oriented as opposed to file-oriented which is the way it was done in 6.0. The older approach is now deprecated. A 6.0 application will still work, but we recommend that the new WSDL be used for all applications going forward. The new API uses ITIL terminology, not legacy Service Manager terminology. In SC 6.0, you had to know that to create an incident, you had to manipulate the probsummary file. Specifically, you had to do a probsummaryAdd operation on it. In 6.1, this requirement to know historic Service Manager terminology goes away. SC 6.1 exposes an IncidentManagement service, which describes an object called an Incident, and defines a set of operations like CreateIncident, UpdateIncident, ResolveIncident, and CloseIncident. And the fields contained in an Incident object have rational names, rather than ambiguous or historic names. We use IncidentID rather than number for example. Well look at how this renaming or aliasing works later. And we also are excluding most of the fields in probsummary from the new Incident object. Only about 10% or less of the fields in probsummary are needed for most applications. Frankly, theres a lot of historic stuff that has accumulated in probsummary over the years due to the inability to delete fields from files in Service Manager. In 6.1, we no longer publish these old fields, via an exclusion facility well look at later. Another important aspect of the new WSDL in 6.1 is that it groups all the files you need together into a service. In 6.0, if you wanted to create a SOAP application to do change management related things, you had to not only know about cm3r and cm3t, but you had to make separate WSDL requests for those files and combine the resulting generated code into one project. In 6.1, this is done automatically. All of this grouping, aliasing, and exclusion functionality can be thought of as an abstraction layer that protects customer SOAP applications from changes in the low-level Service Manager schema. If we decide to do away with the file known as probsummary in some future applications release, a SOAP client which manipulates Incidents will still work.

363

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

364

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

365

Presentation Title

366

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

367

Presentation Title

368

Presentation Title

369

Presentation Title

370

Presentation Title

Streamline business processes by sharing data and processes with multiple applications Enable management to make informed business decisions based on comprehensive infrastructure view Improve data quality by eliminating redundant data gathering efforts Pricing is consistent with the value we provide. Connect-It adds a lot of value to the PRGN solutions. Implementation time is reduced compared to full EAI tools which also cost significantly more in both implementation time and license acquisition. Because our tool is so simple, it runs with almost no maintenance. This is really THE differentiator: our competitors offer single gateways to inventory gathering tools at low price or complex EAI solutions at very high price. We offer best of both.

371

Presentation Title

372

Presentation Title

373

Presentation Title

374

Presentation Title

10/19/07 - The SM7 connector won't be available until ConnectIt 3.81, which is due out in a month or so.

375

Presentation Title

376

Presentation Title

377

Presentation Title

378

Presentation Title

379

380

Presentation Title

381

382

Presentation Title

383

Presentation Title

384

Presentation Title

385

Presentation Title

Instructor notes
[Copy and paste this text box on notes pages for all slides]

386

Presentation Title

387

Presentation Title

388

Presentation Title

389

Presentation Title

390

Presentation Title

391

SM7.00 I.E.

392