I am going to write about our slack integration with AWS and SAP to transport SAPUI5 applications to target system. We are improving this integration everyday and adding new functionalities. It is really fun to do and also improving our efficiency.
TL;DR
We created a custom slack application and a command to trigger an API through AWS and finally initiate a request collection in SAP via REST API and release to target system.
Landspace
We are building planning applications on top of BW 7.5 where users can create master data, input their planning data, run cost allocations and report it via several options. They are both backend and frontend heavy applications. Our applications were built by following a simplified OData architecture which i wrote a blog about it.
We are using VSCode to built UI5 applications. Entire bundling, CI/CD operations are done in Azure DevOps and pushed from Azure DevOps repository to SAP system as below diagram.
Later on, developers are notified from the slack regarding the deployed application.
Problem
During the initial implementation, there was no CI/CD pipeline and we were bundling the applications manually via UI5-CLI. Along to way, I have automated deployment to server from the Azure DevOps repository. It really helped us for code review and deployment with a simple CI/CD operation. No one has to run CLI and push to server manually. Somedays i was even approving pull requests via mobile phone and letting the functional team to do their tests. Later I added slack notification once deployment has been finished.
Still we had one problem which was transporting from development system to QA system. This part was more related to frontend issues or new requests for frontend layer. We were applying quick fixes on UI5, deploying to server via Azure DevOps, collecting a transport of copies request (not to release main workbench TR) and transporting to QA. These steps were getting more and more frequent and we had to do something about it. It was really getting annoying for the team to collect TOC and transport it.
We didin’t want to release our workbench request for not to increase production transport queue on each transport. For these cases, TOC is the best. You can easily set your target. Even for edge cases, you can transport from DEV to PROD directly
This repetitive work should be automated!
You’re either the one that creates the automation or you’re getting automated
Solution
I decided create a Slack application to initiate transport from Slack for QA system. Idea was simple, Slack will send a request to an endpoint and process will start. Here there are some rules and suggestions from Slack layer. Slack sends a POST request to a public HTTPS url with the content of request. We just need to parse and do the action.
Response should be sent in 3 second or Slack will send back “timeout” error. There are some rules regarding responses.
Below is the full diagram of how entire process works.
Slack sends a request to AWS API Gateway and from there it triggers an endpoint on Lambda function. Lambda is actually our serverless backend. It will capture the request based on your selected environment (NodeJS,Python, Go, Ruby, .NET Core etc), process and return a response back to API Gateway. Good part about Lambda is, we don’t need to expose any public REST API from SAP layer. We can hide all security and authorization to Lambda function and process how we want.
AWS is acting like a middleware where it hides our SAP endpoint, authentication and all other complexity and expose a public URL via API Gateway.
I will explain details below. Not as a tutorial but briefly.
Slack Application
First, we need to create our application from Slack API page.
I created an application named Spock.
Why Spock ? Because he is one of my favorite character from the Star Trek :). Especially on Star Trek Discovery.
Once application has been created, we need to configure our application for commands.
There are some important configuration on Slack for our application.
Incoming Webhooks: If you want to send notifications to your developers, you can use here. A simple post request made to the URL provided by Slack will make your text message to appear in chat window. You can even send complicated messages to appear selections like dropdown, checkbox, radiobutton, user selection etc..
Interactivity & Shortcuts: Provide shorts on the slack applications once the user click shortcuts button. Sample is below;
Slash Commands: This is the command section where we type our commands like /command_name param1 param2 param3….. . We will use this section to configure our transport command.
I have used /beamApp <application_name> <target_system>
Just create your command. Request URL will be our AWS API Gateway url. I will explain on that section. Once command is completed, Slack might as you to re-install your app to the channel. Just proceed on steps and you will see command will be available on your Slack app.
Once command executed, below content (depending on your command design) will be posted to target URL
token=XXX&team_id=YYY&team_domain=ZZZ&channel_id=1111&channel_name=aaa&user_id=111&user_name=bilen&
command=%2Fbeamapp&text=ZAPP1+QA&api_app_id=123123&
is_enterprise_install=false&response_url=<response_url>&trigger_id=123123"
There can be one issue for you here, if somehow you don’t want to use AWS layer and straight away connect to your public SAP REST API (which is a bit dangerous) you have to set all SSL configs from STRUST or slack won’t be able to talk to SAP.
So lets create command;
AWS Layer
Lambda
AWS Lambda is a serverless platform. Actually this is your backend where you process the API call and write your codes accordingly. It is an event driven platform where it will capture the event and return a response. You can do your SAP REST API authentication or any other complicated process here. You can choose any technology you want from below list. I am using Python for this development.
Here only problem is, you won’t really have freedom to run npm install for NodeJS or pip install for Python. There are some ways to do this dynamically but ideally you need to install all required packages on your local, zip entire folder and upload to Lambda.
Below folders are created after the installation of requests package of Python. Same will be applied if you install axios for nodeJs.
Blurry area, i am authenticating to my SAP server and triggering the REST API in SAP Server.
myObj = event.get('body') will be storing the entire data coming from the Slack. This data is sent directly to SAP and i need to parse there what application has been requested and for which target.
Basically, Lambda will capture the event details, process, call the REST API in SAP and return response back to API Gateway. API Gateway will forward same response to Slack back. This is how we can see the response from SAP.
API Gateway
API Gateway is the frontdoor to handle all requests before it forwards to your backend. You can think like SAP Gateway. How they work is similar. In SAP Gateway also once OData request has been reached to the Gateway, it forwards to your service based on parameters and finally triggers your class.
API Gateway also does the same think. It handles the request and forwards to the API Lambda which we wrote above. All these forwarding can be configured easily from AWS panel. You can even do live streaming with WebSocket API (Which i am going to try with ABAP Push Channels soon)
From above, REST API protocol is the one we need. You can also see “works with the following” section that Lambda is included.
First we need to create resource. This is same as SAP REST API creation steps. You create your handler, resource class and corresponding endpoint classes. After we create resource, we create a our methods (GET/POST/PUT …) and map to the corresponding Lambda function.
Thats all for API Gateway configuration. Once we trigger our command from slack, it will call api from Api Gateway via POST request and this request will be forwarded to AWS Lambda which is our backend. Now all we need to do is, call our REST API from SAP and get the response.
SAP Layer
REST API
Here we create a service endpoint in SICF tcode and assign to our REST handler.
Rest Handler is similar to AWS API Gateway. It is triggered once request reaches to that endpoint and decides what class to trigger on Resource (remember Resource is similar to our AWS Lambda).
I had a class which i was using for CI/CD pipeline operations in my system from Azure, so i used same class here. Request from AWS Lambda (which i trigger from Python) will be reaching here.
Rest is your abap skills. You can take the request and process how you want and get back response. Please be aware, you have 3 seconds for all these process else slack will raise timeout error.
Release TR
First i created a TOC by setting the target based on coming parameter from the SLACK. I used below function for this
TR_INSERT_REQUEST_WITH_TASKS
Rather than adding objects one by one (MIME objects are really complicated to add and find the correct ones), I simply created a package for each application. With a BDC recording, i added entire package content to the above request number and release. Initially i added transport as well but i split transport event to separate endpoint later on. Sometimes there are on going UAT’s and we might need to wait for a while to pull the request. It is optional, you can embed transport as well together with release.
Later on we just need to return response.
You can return response to the user who requested this or you can post to entire channel. You can response with a styled content or with buttons for confirmation, there are really endless functionality here.
Thats all!
Below you can find recording during while i am moving an application.
You can customize the look and feel of your commands including buttons, radiobuttons, checkbox, selections etc. Slack has a block kit builder for this;
Below is a screenshot. Based on your response coming from the endpoint, you can generate buttons on screen and request approvals, trigger workflows or anything you need for your scenarios.
Source: sap.com
No comments:
Post a Comment