This blog post outlines the solution we have built and demonstrated in a recent API Hackathon organized at my workplace.
As most of the organizations, we also use SAP Solution Manager for our Change and Release Management (ChaRM).
In our customized ChaRM process, we have about 7 different approvals and 5 checklists throughout the lifecycle of a change document. For each of these approvals and checklists, we need to log into the solution manager ChaRM portal, search for the change document and review information. Some status changes have built in validations however many do not.
We saw an opportunity here to save time in performing a few basic prerequisite checks at different stages.
Microsoft Bot Framework SDK has been used to build this chatbot. Thanks to dj.adams.sap “Hands-on SAP dev with qmacro” series, we were quite comfortable with node.js, which we have used for this build.
We started with the Bot Builder Sample 13.Core-bot and built our way around the requirement. The samples were very helpful and run straight out of the box. They are very easy to understand. All Bot Builder samples are accessible here https://github.com/microsoft/BotBuilder-Samples
They do say that Node.js Ver 10.14 is needed but we managed with Ver 8.11.
AZURE Cloud Platform
Deploying bots onto Azure Cloud can be done in 30min even for a first-timer. The documentation available is quite helpful.
How to deploy a bot onto Azure Cloud.
We hosted our code on GitHub and linked it to the Bot App running on Azure. So, upon every commit of our code, the Bot Code gets regenerated and we were able to test end to end almost instantly.
Azure has bot channels for easier deployment onto services like Facebook, MS Teams, Skype, Slack. We added our bot onto Microsoft Teams for this event. This allowed us to access MS teams bot even from a mobile.
Luis.ai
One of the use cases during this hackathon was prerequisite checks during an Object check and Technical Approval Step.
After creating an application in luis.ai, below is the intent training that has been added. Scores are automatically determined upon selecting TRAIN.
Within each utterance, entity identification needs to be done during the BUILD. Could be a single word or a combination of words. Composite entities can be created too.
The TEST Module provides instant results and responses. It also provides calculated intent.
After TRAINing the model and PUBLISHing it, all you need is the Application ID and Endpoint Key. Calling Luis.ai from the bot is very easy. Here is a sample call from the bot.
Solution Manager 7.2
Within Solution Manager, we have built a custom OData service reusing the existing validations of ChaRM. OData V2 service was exposed over the Gateway server. Same age old OData nothing fancy here.
We ensured that the data is Junk to the core and used Display only accesses for the test user communicating with SAP.
API Middleware
We had to use the Mulesoft Anypoint platform for this Hackathon. And yes this was the first time we heard about it. After living in ABAP for a decade this was certainly new for us.
In Mulesoft API Exchange, we attempted to create API using the OData V2 Metadata and it was not an easy task. There are tools to convert OData V4 to RAML format which can be imported into Anypoint studio and generate the mapping. However, there was nothing for OData V2. So, I converted it into OAS ( Open API Specification ) (https://github.com/oasis-tcs/odata-openapi) and attempted conversion from OAS to RAML using the Mulesoft tool (https://mulesoft.github.io/oas-raml-converter/)
After all this, the RAML did not work.
So, I fell back onto my trusty REST. Created a HTTP listener, a HTTP request call module and added some mapping logic to prepare the query parameters to suit the OData Entity Call.
Within an hour, the application was up and running. Calling it from the BOT was easier than ever.
We have used Microsft Adaptive Cards (https://adaptivecards.io/) to design cards in our chat communication.
The card designer (https://adaptivecards.io/designer/) is similar to the one showcased at 2019 SAP TechEd which will be part of SAP Business Application Studio.
Of course, it is possible. Here are some alternatives.
It might be a challenge to build use cases for current production problems using these products when they are not accessible within your organization. We wanted to showcase what is possible with open technologies before investing into something solid. This was meant to be more of a sneak-peek into problem-solving and also learning.
It might have taken 5 minutes to read this blog, maybe less if you skimmed through the details. It certainly took more than that for us to build it.
From Ideation to build and finally the Hackathon Demo, we spent a couple of hours each day outside work for three weeks. It has been a wonderful learning experience to the most part delving into the world beyond ABAP.
There definitely will be better alternatives for the solution we prepared. It's the learning that mattered for us when we enrolled for this.
At the End...
INTRODUCTION
As most of the organizations, we also use SAP Solution Manager for our Change and Release Management (ChaRM).
In our customized ChaRM process, we have about 7 different approvals and 5 checklists throughout the lifecycle of a change document. For each of these approvals and checklists, we need to log into the solution manager ChaRM portal, search for the change document and review information. Some status changes have built in validations however many do not.
We saw an opportunity here to save time in performing a few basic prerequisite checks at different stages.
SOLUTION
Our Solution, is a Chatbot built using the Microsoft Bot Framework SDK, hosted on AZURE cloud platform, using Microsoft Cognitive Service Luis.ai for intent classification, our Solution Manager 7.2 sandbox for backend, and Mulesoft Anypoint as our API Middleware.
Chatbot
Microsoft Bot Framework SDK has been used to build this chatbot. Thanks to dj.adams.sap “Hands-on SAP dev with qmacro” series, we were quite comfortable with node.js, which we have used for this build.
We started with the Bot Builder Sample 13.Core-bot and built our way around the requirement. The samples were very helpful and run straight out of the box. They are very easy to understand. All Bot Builder samples are accessible here https://github.com/microsoft/BotBuilder-Samples
They do say that Node.js Ver 10.14 is needed but we managed with Ver 8.11.
AZURE Cloud Platform
Deploying bots onto Azure Cloud can be done in 30min even for a first-timer. The documentation available is quite helpful.
How to deploy a bot onto Azure Cloud.
We hosted our code on GitHub and linked it to the Bot App running on Azure. So, upon every commit of our code, the Bot Code gets regenerated and we were able to test end to end almost instantly.
Azure has bot channels for easier deployment onto services like Facebook, MS Teams, Skype, Slack. We added our bot onto Microsoft Teams for this event. This allowed us to access MS teams bot even from a mobile.
Add bots for personal chats, group chats, and channels in Microsoft Teams.
Luis.ai
Language Understanding (LUIS) is a machine learning-based service to build natural language understanding.
One of the use cases during this hackathon was prerequisite checks during an Object check and Technical Approval Step.
After creating an application in luis.ai, below is the intent training that has been added. Scores are automatically determined upon selecting TRAIN.
Within each utterance, entity identification needs to be done during the BUILD. Could be a single word or a combination of words. Composite entities can be created too.
The TEST Module provides instant results and responses. It also provides calculated intent.After TRAINing the model and PUBLISHing it, all you need is the Application ID and Endpoint Key. Calling Luis.ai from the bot is very easy. Here is a sample call from the bot.
const serviceRecognition = new LuisRecognizer({
applicationId: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", //process.env.LuisAppId,
endpointKey: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", //process.env.LuisAPIKey,
endpoint: 'https://xxxxxx.api.cognitive.microsoft.com'
}, {
includeAllIntents: true,
includeInstanceData: true
}, true);
const results = await serviceRecognition.recognize(stepContext.context);
changeDocuments.intent = LuisRecognizer.topIntent(results);
switch (changeDocuments.intent) {
case 'None':
// Catch all for unhandled intents
const didntUnderstandMessageText = `Sorry, I didn't get that. Please try asking in a different way (intent was ${ LuisRecognizer.topIntent(luisResult) })`;
await stepContext.context.sendActivity(didntUnderstandMessageText, didntUnderstandMessageText, InputHints.IgnoringInput);
break;
default:
return await stepContext.beginDialog('controlDialog', changeDocuments);
}Solution Manager 7.2
Within Solution Manager, we have built a custom OData service reusing the existing validations of ChaRM. OData V2 service was exposed over the Gateway server. Same age old OData nothing fancy here.
We ensured that the data is Junk to the core and used Display only accesses for the test user communicating with SAP.
API Middleware
We had to use the Mulesoft Anypoint platform for this Hackathon. And yes this was the first time we heard about it. After living in ABAP for a decade this was certainly new for us.
In Mulesoft API Exchange, we attempted to create API using the OData V2 Metadata and it was not an easy task. There are tools to convert OData V4 to RAML format which can be imported into Anypoint studio and generate the mapping. However, there was nothing for OData V2. So, I converted it into OAS ( Open API Specification ) (https://github.com/oasis-tcs/odata-openapi) and attempted conversion from OAS to RAML using the Mulesoft tool (https://mulesoft.github.io/oas-raml-converter/)
After all this, the RAML did not work.
So, I fell back onto my trusty REST. Created a HTTP listener, a HTTP request call module and added some mapping logic to prepare the query parameters to suit the OData Entity Call.
Within an hour, the application was up and running. Calling it from the BOT was easier than ever.
const url = "http://xxxx.cloudhub.io/changeDocument?objectId=" + stepContext.values.changeDocument.number + "&intent=" + stepContext.values.changeDocument.intent;
let response = await fetch(url)
.then((response) => response.json())
.then(data => {
return data;
})
.catch(error => {
console.error(error);
});END RESULT
We have used Microsft Adaptive Cards (https://adaptivecards.io/) to design cards in our chat communication.
The card designer (https://adaptivecards.io/designer/) is similar to the one showcased at 2019 SAP TechEd which will be part of SAP Business Application Studio.
Can we do it with only SAP Products?
Of course, it is possible. Here are some alternatives.
| Microsoft Teams | This will need a custom Application developed that will connect to API Endpoint |
| Mulesoft Middleware | api.sap.com can be used |
| MS Bot Builder | SAP Conversation UI can be used without any Boilerplate Codes |
| AZURE Bot Web Client | SAP Cloud Platform Bot Web Client can be used |
It might be a challenge to build use cases for current production problems using these products when they are not accessible within your organization. We wanted to showcase what is possible with open technologies before investing into something solid. This was meant to be more of a sneak-peek into problem-solving and also learning.
How long did this take us to build?
It might have taken 5 minutes to read this blog, maybe less if you skimmed through the details. It certainly took more than that for us to build it.
From Ideation to build and finally the Hackathon Demo, we spent a couple of hours each day outside work for three weeks. It has been a wonderful learning experience to the most part delving into the world beyond ABAP.
There definitely will be better alternatives for the solution we prepared. It's the learning that mattered for us when we enrolled for this.
At the End...
We collaborated, we learnt, we presented and...WE WON !!!
#LEARNSHAREREPEAT
- SAP Managed Tags:
7 Comments
