In this weblog series I want to show how to build an expert system using semantic techniques. In the first part I introduced as a showcase an expert system that can analyse error sitations by classifying BAL messages. In the second part I showed how this classification can be performed using ontologies. Then I proposed to keep the knowledge base in a wiki. Now I will discuss how to expose facts about system diagnosis (think of BAL protocols, logs, dumps).
REST & Groovy kick ***!
From a technical perspective this is easy: We transform these data into XML and expose them as REST Web Services using the ICF framework. A lot of people explained in detail how to do that. I recommend the blogs, books, lectures of SAP Mentors Tom Jung, DJ Adams, Thorsten Franz and me.
Consuming REST Web Services in Groovy and transformation into in ontology is a really easy task. You'll find examples how to do here http://www.ibm.com/developerworks/java/library/j-pg05199/index.html and here http://groovy.codehaus.org/Using+MarkupBuilder+for+Agile+XML+creation.
From e technical point of view it is easy: just provide an REST service that takes the external ID of an BAL log and give it back as XML in the following way:
<Protocol>
<Message>
<OBJECT>FICA</OBJECT>
<SUBOBJECT>FPG1</SUBOBJECT>
<CLASS>>U</CLASS>
<NUMBER>425</NUMBER>
<TYPE>E</TYPE>
</Message>
<Message>
<OBJECT>FICA</OBJECT>
<SUBOBJECT>FPG1</SUBOBJECT>
<CLASS>F5</CLASS>
<NUMBER>808</NUMBER>
<TYPE>E</TYPE>
</Message>
</Protocol>This will work - but should we recommend it?
What should a vocabulary to describe error situations should look like?
The question what a "good" vocabulary for system diagnosis would look like is difficult to answer because it depends on who do you ask. From the point of view of an expert system resp. wiki it should be possible to express logical conditions about facts effectively because those conditions are crucial for perform reasoning. Looking at the wiki we have the requirement that the knowledge database should be easy to maintain which means that we don't have to deal with the vocabulary at all - we need a way to maintain logical expressions in a simple way - perhaps using different wiki extesions. The system that exposes facts can code them in any XML dialect - perhaps an XML schema compliant data type is easier to generate than vocabuleries based on semantic web standards - but both is possible.
But what about the general situation? What will happen in a system landscape with many systems and perhaps more than one application in a system? Let me give you an example: even AS ABAP as foundation of SAP ERP consists of many applications: the even mentioned business application log, the workflow runtime, the enqeue server, the job log and much more. And the whole situation gets even worse when we integrate non SAP system like output management systems, document management systems, data bases as we see on the following picture:
I doubt there is one common vocabulary that is to formulate all facts we need for automated error analysis but it would be interesting to discuss this topic with an expert about error protocols like SNMP which ubiquitous and well understood by SAP Solution Manager. So at the moment I believe that we should try to do standardization but in many cases there will be many different proprietary protocols which are optimized to express concise facts of each single system / application.
How to deal with different vocabularies?
In my opinion the expert system as scetched the second part of this series in is well prepared for this situation. If you remind the second part of this blog series the knowledge database was modelled in semantic web standards. The knowledge database consists error classes defined by logical expressions. All those error classes can live side by side. These logical conditions can relate to different objects like messages, work items and so on. It is possible to keep them all in a single ontology side by side as long as different vocabularies can be distinguished using different namespaces. A single logical expression can use entities from different vocabularies, too. As a consequence there can be many different vocabularies as long as we provide ways to translate them into semantic web standards like RDF and OWL or express them as RDF / OWL directly.
But this doesn't mean that every vocabulary based on OWL fits our needs. One drawback are OWL's imitations doing calculations. So if the knowledge base uses complex calculations these have to be done within the system that exposes his diagnosis information and they have to part of the vocabulary.
Summary
In this part of my weblog series I showed that using XML based protocols we are well prepared to expose system diagnosis data. REST web services have the advantage that they can expose their data in many formats like human readable HTTP as well as semantic web standards which can be put into the expert database without further translation.
In my opinion automated error analysis could be a killer app which will help to reduce maintenance costs of an IT landscape. But before this will become reality we will spend some effort until we find a universal standard - perhaps a Web 3.0 successor of SNMP. And if comes out that there will be no usable common standard we have to get more experience how to expose system diagnosis data in a way that expert systems can deal with it effectively.
