TAKE NOTE (Insights and Emerging Technology)
SAP announced that it has acquired Contextor SAS, a European leader in the design and integration of robotic process automation (RPA), to help SAP accelerate the development and expansion of its SAP Leonardo Machine Learning portfolio.
Contextor’s RPA technology relieves business software users from performing repetitive tasks and enables both attended and unattended RPA within and across applications. To date, Contextor’s customers have deployed more than 100,000 bots automating business processes.
RPA will help to simplify user interface interactions across SAP and non-SAP applications. Contextor’s RPA will be combined with SAP Cloud Platform and conversational AI technology and document processing capabilities provided by SAP Leonardo Machine Learning to deliver intelligent RPA, which SAP plans to include in key SAP solutions.
“With intelligent RPA accelerated by Contextor, businesses will be able to achieve the high automation level necessary to become intelligent enterprises,” said Markus Noga, head, machine learning, SAP. “The acquisition is a big step towards orchestrating process automation and will help SAP inject RPA capabilities into our applications, first and foremost into SAP S/4HANA.”
The integration of intelligent RPA into SAP S/4HANA is expected in the first half of 2019. Other SAP applications will follow soon thereafter.
With Contextor’s RPA technology, SAP plans to automate half of all the business processes supported by its SAP ERP software over the next three years. Contextor, based in the Paris region, was founded in 2000 and is specialized in the research and development of RPA software to deliver clever, nimble and efficient application assistants, wizards and stand-alone bots.
Read More
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
What is SAP BW Powered By HANA
SAP Business Warehouse (BW) powered by HANA also known as BW on HANA (BWoH) is SAP’s data modeling, warehousing, and reporting tool built on the HANA database. SAP BW on HANA (BWoH) runs on the HANA database and therefore it is simpler and faster. Please note this is SAP BW running on a HANA Database, this is not BW/4HANA, which is part of the evolution of BW that is completely optimized and tailored to SAP HANA. The BW/4HANA code can only run on SAP HANA as it is interwoven with SAP HANA engines and libraries.
Before we dive in, it would be a good idea to understand what HANA is. When correctly implemented, SAP HANA conveys outstanding results and performance, analytic intelligence, integration capabilities, data processing, and improved ROIs of the SAP landscape with swift time-to-value. We have a great blog on this called The ABAP Developer Road Map to SAP HANA, it is definitely worth a read – especially if your a developer.
OK, let’s go back a bit and look at how SAP HANA BW evolved…
When you run SAP Business Warehouse (BW) on HANA, data is consumed in a data warehouse (DW). SAP BW combines DW capabilities like data integration and modeling with HANA’s in-memory processing to increase speed and data modeling capabilities. Complexity is reduced because transformations and DSOs are now in the HANA environment. This allows for faster processing, improved data load performance, optimized query processing, and additional reporting features. This next-generation tool integrates with other SAP and third-party solutions and also allows you to process unstructured, geospatial, and Hadoop-based data. Plus the new UI is more intuitive and user-friendly
Drawbacks to Pre-HANA BW
Let’s take a look at how SAP BW powered by HANA is different from the previous generation. Before HANA, running SAP BW on Oracle or another database was extremely complex. This required administering the SAP ERP system, an OLTP database, and a separate database for the INFO-Cubes needed for staging, aggregations, and reporting. You had to stage data and use INFO-Cubes for aggregations and reporting. Other challenges of running SAP BW with third-party databases included:
- Lack of real-time reporting capability. Data was moved to the warehouse in batches, preventing real-time reporting.
- Time-consuming structural changes. Enhancements and upgrades were time-consuming and often ran into compatibility problems. Even the simplest structural change could take 2-12 months.
- Applications ran independently. Each application had to be monitored and optimized individually, so performance tuning was also time-consuming.
- Limited granularity levels. Due to the aggregation limitations of SAP BW, you could not pull data at different granularity levels.
Now the aggregations are done at the HANA layer which makes administration much simpler. Instead of two separate databases, the HANA database handles both transaction Processing (OLTP) and Analytics Processing (OLAP). And, as mentioned earlier, HANA is faster because data is processed in memory, so there are no batching-delays.
Activities like the activation step for DataStore Objects, or DSOs, and certain types of transformations are functionally the same on HANA as on other databases, but the actual processing has been moved into HANA rather than happening on the BW application server as it does with other databases. This cuts down on data movement, making it possible to execute these activities much faster with BW on HANA.
BW Powered By HANA Overview
Q&A (Post your questions and get the answers you need)
Q. HI, Using new abap conventions, I am declaring an internal table inline while selecting from table ZABC. I want to add few more fields to the internal table based on calculations and other assignments. Will I have to declare a new internal table using types, or is there any way yo insert more fields into the created internal table?
A. I am assuming you mean during the select from ZABC. You can insert fields automatically that do not exist on the source table, based on calculations using the alias function during the select.
You can read about it HERE
Below is example code:
CONSTANTS: lc_carrid TYPE s_carr_id VALUE ‘UA’,
lc_connid TYPE s_conn_id VALUE ‘941’.
SELECT carrid, connid, price, seatsocc_b, seatsocc_f,
( ( seatsocc_b + seatsocc_f ) ) * price AS total
FROM sflight
WHERE carrid = @lc_carrid
AND connid = @lc_connid
INTO TABLE @data(lt_sflight).
Break-point.
You can see I am using the IDES table SFLIGHT as the source, I was able to use the new 7.4 syntax to combine the occupied seats in First & Business Class and multiply by the Price and store it the field total whilst declaring the entire target table lt_sflight in-line during execution.
The field “total” does not exist on SFLIGHT or lt_sflight, and is created in-line because of using the alias “AS total” in the Select statement.
Hope this helps!