Author: admin

Yesterday I had a great pleasure to have a lunch with Artur Górnik, one of HANA “black belts” in SAP MEE region. He did a customer workshop the day before here in Wrocław. And then our lunch turned into 3 hours discussion about all things SAP data managment, interrupted – unfortunately – by his departing train

One of the topics we discussed was using different SQL clients with SAP HANA Express server-only installation. The discussion was triggered by a blog SQL Clients and SAP HANA 2.0 posted by my teammate Craig Cmehil. (As a true black belt) Artur told me that his primary client when working with HANA database is still hdbsql, i.e. the command line interface.

I recently spent some time working with SAP Vora developer edition. And if you worked with it as well, then you might have came across the tool called beeline there. It is a command line shell that uses Apache Hive JDBC to connect to SAP Vora. But the reason why I brought it here now was the note that it was based on another open source project SQLLine. Accordingly to their documentation:

SQLLine is a pure-Java console based utility for connecting to relational databases and executing SQL commands. It is similar to other command-line database access utilities… Since it is pure-Java, it is platform independent, and will run on any platform that can run Java 1.3 or higher.

So, it is one CLI to rule them all as it seems! The author stopped developing it in 2005, but some more search and I found a branch that is still being developed these days: https://github.com/julianhyde/sqlline. Ok, pulling it from git (using WSL on my Windows 10), installing Maven and configuring it to use SAP JVM, running the build process, and here it is: freshly compiled SQLLine.

As described in the Getting Started I copied sqlline.bat and sqlline-VERSION-jar-with-dependencies.jar into one directlry plus copied two JDBC driver files there as well:

* ngdbc.jar for HANA 2.0 SPS 2 Express [called HXE further]
* sajdbc4.jar for SAP SQL Anywhere 17 Developer edition [called SQLA further]

Let me try now. C:Toolssqllineexe>sqlline.bat sqlline version ??? sqlline>

I am not sure why it does not know the version, but at least I am in the shell. Let’s connect to HXE that I activated in SAP CAL. sqlline> !connect jdbc:sap://vhcalhxedb:39015 Enter username for jdbc:sap://vhcalhxedb:39015: SYSTEM Enter password for jdbc:sap://vhcalhxedb:39015: ******** 0: jdbc:sap://vhcalhxedb:39015> select * from dummy; +——-+ | DUMMY | +——-+ | X | +——-+ 1 row selected (0.472 seconds) 0: jdbc:sap://vhcalhxedb:39015>

So far, so good. Now let me connect to SQLA’s standard demo databse I have on my Windows 10 laptop. 0: jdbc:sap://vhcalhxedb:39015> !connect jdbc:sqlanywhere:eng=demo17 Enter username for jdbc:sqlanywhere:eng=demo17: dba Enter password for jdbc:sqlanywhere:eng=demo17: *** 1: jdbc:sqlanywhere:eng=demo17> select * from dummy; +————-+ | dummy_col | +————-+ | 0 | +————-+ 1 row selected (0.004 seconds) 1: jdbc:sqlanywhere:eng=demo17>

Ok, works as well. And how about SQLA that I installed on my Raspberry Pi at home and started the same demo database? 1: jdbc:sqlanywhere:eng=demo17> !connect jdbc:sqlanywhere:Host=192.168.1.224;ServerName=mydemo;DatabaseName=demo Enter username for jdbc:sqlanywhere:Host=192.168.1.224;ServerName=mydemo;DatabaseName=demo: dba Enter password for jdbc:sqlanywhere:Host=192.168.1.224;ServerName=mydemo;DatabaseName=demo: *** 2: jdbc:sqlanywhere:Host=192.168.1.224> select * from dummy; +————-+ | dummy_col | +————-+ | 0 | +————-+ 1 row selected (0.015 seconds) 2: jdbc:sqlanywhere:Host=192.168.1.224>

Now I have my SQLLine client connected to three different database servers (one HANA and two SQL Anywhere; one in the cloud, one on my laptop, and one in my home network). And I can switch between them from within the same command line. 2: jdbc:sqlanywhere:Host=192.168.1.224> !list 3 active connections: #0 open jdbc:sap://vhcalhxedb:39015 #1 open jdbc:sqlanywhere:eng=demo17 #2 open jdbc:sqlanywhere:Host=192.168.1.224;ServerName=mydemo;DatabaseName=demo 2: jdbc:sqlanywhere:Host=192.168.1.224> !go 0 0: jdbc:sap://vhcalhxedb:39015>

But what is cool is that I can submit an SQL statement (assuming the same syntax and db objects, like in this example) to all at once: 0: jdbc:sap://vhcalhxedb:39015> !all select * from dummy; Executing SQL against: jdbc:sap://vhcalhxedb:39015 +——-+ | DUMMY | +——-+ | X | +——-+ 1 row selected (0.45 seconds) Executing SQL against: jdbc:sqlanywhere:eng=demo17 +————-+ | dummy_col | +————-+ | 0 | +————-+ 1 row selected (0.001 seconds) Executing SQL against: jdbc:sqlanywhere:Host=192.168.1.224;ServerName=mydemo;DatabaseName=demo +————-+ | dummy_col | +————-+ | 0 | +————-+ 1 row selected (0.014 seconds) 0: jdbc:sap://vhcalhxedb:39015>

And what is über-cool, is that I can run examples from my Introduction to SAP HANA Spatial engine tutorials on all connections, because both HXE and SQLA support geospatial data. 0: jdbc:sap://vhcalhxedb:39015> !all SELECT NEW ST_Point (1,1).ST_Within(NEW ST_Point(0, 0).ST_Buffer(2)) FROM dummy; Executing SQL against: jdbc:sap://vhcalhxedb:39015 +—————————————————–+ | ST_POINT(1,1).ST_WITHIN(ST_POINT(0,0).ST_BUFFER(2)) | +—————————————————–+ | 1 | +—————————————————–+ 1 row selected (0.27 seconds) Executing SQL against: jdbc:sqlanywhere:eng=demo17 +————————————————————-+ | new ST_Point(1,1).ST_Within(new ST_Point(0,0).ST_Buffer(2)) | +————————————————————-+ | true | +————————————————————-+ 1 row selected (0.012 seconds) Executing SQL against: jdbc:sqlanywhere:Host=192.168.1.224;ServerName=mydemo;DatabaseName=demo +————————————————————-+ | new ST_Point(1,1).ST_Within(new ST_Point(0,0).ST_Buffer(2)) | +————————————————————-+ | true | +————————————————————-+ 1 row selected (0.058 seconds) 0: jdbc:sap://vhcalhxedb:39015>

I really wanted to try it out, so it was quite quick and dirty installation and test. I haven’t tested all the different SQLLine commands and all the different SQL statements and outputs. If you try more, and especially if you break it – please share here in the comments. Much appreciated!

-Vitaliy, aka @Sygyzmundovych http://bit.ly/2yt484P #SAP #SAPCloud #AI

SAP TechEd Las Vegas, U.S.A. Venetian|Palazzo Congress Center September 25–29, 2017

SAP TechEd Bangalore, India Bangalore International Exhibition Center October 25–27, 2017

SAP TechEd Barcelona, Spain Fira de Barcelona, Gran Via Venue November 14–16, 2017

After a successful week in Las Vegas we are bring some excellent Predictive & Machine Learning content to Bangalore. We will be bringing you a variety of Lectures, Hands-on & Roadmap sessions to explore the Advanced Analytics portfolio:

Learn – Lectures

ANA111                Machine Learning in Enterprise Applications

ANA112                Making SAP Applications Smarter by Embedding Machine Learning

ANA113                Machine Learning in the Cloud, the Next Frontier of Predictive Analytics

ANA205                Predictive Analytics and Machine Learning from SAP: What You Need to Know

ANA206                Light a ‘Spark’ on Big Data with Predictive Analytics

ANA820                SAP Predictive Analytics: Road Map

Try – Hands on

ANA164                Operationalizing Machine Learning with Predictive Factory

ANA265                Use Machine Learning from Predictive Analytics to Make Better Decisions

ANA266                Unleashing Machine Learning in SAP BW/4HANA Using Predictive Analytics

ANA363                Creating OEM Solutions with Automated Machine Learning

S4H162                Predictive Capabilities in S/4HANA

Engage – Bangalore

Also feel free to visit us at the booth or at the Networking evening to ask our experts all your predictive and machine learning questions: Jayanta Roy   Herve KAUFFMANN

@apoorva.kumar Suresh Pasumarthi @sreepriya.g

We look forward to seeing you there!!

**Stay tuned for updates on Barcelona** http://bit.ly/2gSB3pr #SAP #SAPCloud #AI

Blockchain has long been resonating beyond the walls of the software industry. Every day, messages circulate about the development of the Bitcoin price index, while startups are competing to create the next earth-shattering business model based on this technology.

Yet what do we really understand about it?

At the peak of the 2008 financial crisis, an individual or a group of individuals acting under the pseudonym Satoshi Nakamoto sent a paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” to a mailing list. It contained a practical solution to a problem that had left virtual currency theorists scratching their heads: the Byzantine General’s Problem.

Creating Consensus Among Decentralized Players

The Byzantine General’s Problem originates in an historical legend at the time of Constantinople’s fall to the Ottoman Empire in 1453. The fortified city could only be successfully overrun with help of carefully planned troop movements coming from various directions. To achieve this, the commanding Ottoman generals had to resort to communicating through messengers. However, the decision about the moment of attack was severely hampered by one key detail: As some of the generals wanted discredit their colleagues to the sultan, they purposefully provided false information to instigate a premature attack. From that point on, none of the generals could be sure if the incoming messages were authentic or not.

The crux of the problem was the issue of consensus, deriving from the fact that the individual decision-makers could not trust one another.

Money and the Role of the Intermediary

The same situation applies to digital transactions of value. How can we reach consensus that a virtual dollar will not be paid out twice? To date, the answer could not have been simpler: by involving an intermediary third party to oversee all transactions; in other words, a bank.

This isn’t always smooth sailing. International payments in the form of SWIFT transferrs often take several days to process due to the various parties involved. This increases the transaction costs and makes small one-off payments inconvenient. The option of being able to cancel a transaction also has its pitfalls; to be able to minimize fraud, providers of irreversible services are required to collect more information about their customers than is usually necessary.

Yet for physical value transactions the problem has been largely resolved. Take the following example: If Alice wants to pay Bob a certain sum of money, it is sufficient for her to hand him a counterfeit-proof coin that represents the respective value. It is impossible for Alice to make two separate payments simultaneously using the same coin.

There have been many attempts to convert the principle of physical currency into the digital world, yet with varying degrees of success. Bitcoin was the first to largely meet these demands.

Cryptographic Signatures and Digital Value

To ensure that digital coins can only be spent by their lawful owners, Bitcoin uses public-key cryptography. This involves a private key made up of randomly-generated numbers, which, in turn also derives a public key. Conversely, public keys cannot be used to derive the corresponding private key. A digital signature is generated from the private key and a set of data. The public key enables users to determine that the signature derives from the corresponding private key, without needing to know it.

Bitcoin also uses the cryptographic hash function, which converts large strings of data into fixed-length data values, otherwise known as a hash. A good hash function is characterized by a high level of security and can assign various input quantities using as few of the same hashes as possible.

Compared to an encryption, this process cannot be reversed. When applied to the same input quantity, the hash function always produces the same hash yet it cannot be attributed to the original input quantity. Every change to the input quantity generates a completely different hash. For this reason, hashes are also known as digital fingerprints.

A coin in the Bitcoin system is ultimately a combination of digital signatures. The coin is passed on when the owner (Alice) digitally signs a hash from the previous transaction and the receiver’s (Bob) public key. For Bob to be sure that Alice has not already used her coin in another transaction, all transactions are publicly available.

Mathematical Race to Reach Consensus

Bitcoin achieves this through a peer-to-peer network. A network node compiles various transactions together in a block, generates a hash from them, and releases it with a time stamp. Each block contains the hash from the previous block, thereby forming a chain: the blockchain.

This brings us back to the “Byzantine General’s Problem”: all nodes must agree on which transaction has taken place first and whether another block should be added to the chain. Bitcoin here uses the so called proof of work method. To add an additional block to the chain, the respective computer nodes are required to solve a complex mathematical puzzle. The node that first finds the solution then shares it with all the other nodes. Once the solution has been verified by them, every node adds the block to their copy of the chain. The process then starts all over again.

To comply with the changing total computing power in the network, the difficulty of the puzzle is constantly adapted, so that new blocks are added to the chain approximately every 10 minutes. If two blocks are found simultaneously, the next block found determines which sub-chain will be kept. The longest chain wins.

Since the puzzle must be re-solved for every change to the block, which is also the case for all subsequent blocks, the chain becomes more secure the longer it becomes. To change it, an attacker would have to re-solve the mathematical puzzle for all blocks before being able to add a new block to the chain. The element of trust, which currently exists in the form of a bank, is thereby contained within blockchain’s mathematical logic.

The Internet of Value

Blockchain functions as a distributed public journal that records irreversible transactions. Users can quickly and cost-effectively verify and audit their transactions without intermediaries.

Use cases of public blockchain have the potential to completely transform existing markets

Blockchain technology use cases are by no means restricted to Bitcoin. Blockchain is far more a message about the transmission of value — the “Internet of Value.” The database serves as the ultimate determination of ownership rights. All kinds of assets that can be transformed into digital twins can be included in blockchain: diamonds, buildings, good deliveries – the possibilities are endless.

Whether this innovation is disruptive or incremental depends on the areas of operation. Reaching consensus within or between companies means evolutionary change, while use cases of public blockchains have the potential to completely transform existing markets.

One blockchain use case is Everledger, a startup that produces digital twins for diamonds. These digital twins are calculated from 40 data points and are stored on blockchain, enabling the stone’s ownership to be traced from when it first mined to when it becomes a piece of jewelry. Over 1 million jewels have already been digitally secured — a real success story.

Learn more about how SAP is bringing blockchain to the enterprise. http://bit.ly/2gSB1Ol #SAP #SAPCloud #AI

Selecting the appropriate technologies is critical during the inception phase of a project. Most recently,  we’ve been adopting a microservices architecture as a solution that satisfies our clients’ needs for modularity and availability.  

As a software engineer at Admios, one of our main tasks included the evaluation of frameworks to develop REST APIs for one of our clients. The end goal was to reunite all their software services in a single-point access portal. https://goo.gl/FxFjF8 #DataIntegration #ML