Over the past few years, many organizations have experienced the benefits of migrating their SAP solutions to Google Cloud. But this migration can do more than reduce IT maintenance costs and make data more secure. By leveraging BigQuery, SAP customers can complement their SAP investments and gain fresh insights by consolidating enterprise data and easily extending it with powerful datasets and machine learning from Google. 

BigQuery is a leading cloud data warehouse, fully managed and serverless, and allows for massive scale, supporting petabyte-scale queries at super-fast speeds. It can easily combine SAP data with additional data sources, such as Google Analytics or Salesforce, and its built-in machine learning lets users operationalize machine learning models using standard SQL — all at a comparatively low cost. 

If your SAP-powered organization is looking to supercharge its analytics with the strength of BigQuery, read on for considerations and recommendations for modeling with SAP data. These guidelines are based on our real-world implementation experience with customers and can serve as a roadmap to the analytics capabilities your business needs.

Considerations for data replication 

Like most technology journeys, this one should start with a business objective. Keeping your intended business value and goals in mind is critical to making the right decisions in the early steps of the design process.

When it comes to replicating the data from an SAP system into BigQuery, there are multiple ways to do it successfully. Decide which method will work best for your organization by answering these questions:

• Does your business need real-time data? Will you need to time travel into past data?
• Which external datasets will you need to join with the replicated data?
• Are the source structures or business logic likely to change? Will you be migrating the SAP source systems any time soon? For instance, will you be moving from SAP ECC to SAP S/4HANA?

You’ll also need to determine whether replication should be done on a table-by-table basis or whether your team can source from pre-built logic. This decision, along with other considerations such as licensing, will influence which replication tool you should use.

Replicating on a table-by-table basis
Replicating tables, especially standard tables in their raw form, allows sources to be reused and ensures more stability of the source structure and functional output. For example, the SAP table for sales order headers (VBAK) is very unlikely to change its structure across different versions of SAP, and the logic that writes to it is also unlikely to change in a way that affects a replicated table. 

Something else to consider: Reconciliation between the source system and the landing table in BigQuery is linear when comparing raw tables, which helps avoid issues in consolidation exercises during critical business processes, such as period-end closing. Since replicated tables aren’t aggregated or subject to process-specific data transformation, the same replicated columns can be reused in different BigQuery views. You can, for instance, replicate the MARA table (the material master) once and use it in as many models as needed. 

Replicating pre-built logic
If you replicate pre-built models, such as those from SAP extractors or CDS views, you don’t need to build the logic in BigQuery, since you’re using existing logic. Some of these extraction objects have embedded delta mechanisms, which may complement a replication tool that can’t handle deltas. This will save initial development time, but it can also lead to challenges if you create new columns, or if customizations or upgrades change the logic behind the extraction. 

It’s also important to note that different extraction processes may transform and load the same source columns multiple times, which creates redundancy in BigQuery and can lead to higher maintenance needs and costs. However, replicating pre-built models may still be a good choice, since doing so can be especially useful for logic that tends to be immutable, such as flattening a hierarchy, or logic that is highly complex.

How you approach replication will also depend on your long-term plans and other key factors — for example, the availability (and curiosity) of your developers, and the time or effort they can put into applying their SQL knowledge to a new data warehouse. 

With either replication approach, bear in mind when designing your replication process that BigQuery is meant to be an append-always database — so post-processing of data and changes will be required in both cases. 

Processing data changes

The replication tool you choose will also determine how data changes are captured (known as CDC – change data capture). If the replication tool allows for it (for example as SAP SLT does) the same patterns described in the CDC with BigQuery documentation also apply to SAP data. 

Because some data, like transactions, are known to be less static than others (e.g., master data), you need to decide what should be scanned in real time, what will require immediate consistency, and what can be processed in batches to manage costs. This decision will be based on the reporting needs from the business.

Consider the SAP table BUT000, containing our example master data for business partners, where we have replicated changes from an SAP ERP system:

In an append-always replication in BigQuery, all updates are received as new records. For example, deleting a record in the source will be represented as a new record in BigQuery with a deletion flag. This applies to whether the records are coming from raw tables like BUT000 itself or pre-aggregated data, as from a BW extractor or a CDS view.

Let’s take a closer look at data coming particularly from the partners “LUCIA” and “RIZ”. The operation flag tells us whether the new record in BigQuery is an insert (I), update (U) or deletion (D), while the timestamps help us identify the latest version of our business partner.

If we want to find the latest updated record for the partners LUCIA and RIZ, this is what the query would look like:

  SELECT partner,
        ARRAY_AGG(i1 ORDER BY i1.recordstamp DESC LIMIT 1) AS row
FROM SAP_ECC.but000 i1 
WHERE partner in ('LUCIA','RIZ')
    GROUP BY partner

With the following result:

After identifying stale records for “LUCIA” and “RIZ” business partners, we can proceed to deleting all stale records for “LUCIA” if we do not want to retain the history. In this example, we are using a different table to which the same replication has been done, for the purpose of comparison and to check that all stale records have been deleted for the selection made and that we only kept last updated records. For example:

  DELETE SAP_HANA.but000 i1
WHERE
i1.recordstamp < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR) AND
i1.recordstamp < (SELECT MAX(recordstamp) FROM SAP_HANA.but000 i2
WHERE
i1.partner = i2.partner
and partner="LUCIA")

You can also use the following query to retrieve stale records for “LUCIA” partner before moving forward with deletion

  SELECT partner, operation_flag, recordstamp  FROM SAP_HANA.but000 i1
WHERE
i1.recordstamp < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR) 
AND
i1.recordstamp < (SELECT MAX(recordstamp) FROM SAP_HANA.but000 i2 
WHERE 
i1.partner = i2.partner
and partner="LUCIA")

Which produces all of the records, except the latest update:

Partitioning and clustering

To limit the number of records scanned in a query, save on cost and achieve the best performance possible, you’ll need to take two important steps: determine partitions and create clusters. 

Partitioning
A partitioned table is one that’s divided into segments, called partitions, which make it easier to manage and query your data. Dividing a large table into smaller partitions improves query performance and controls costs because it reduces the number of bytes read by a query.

You can partition BigQuery tables by:

• Time-unit column: Tables are partitioned based on a “timestamp,” “date,” or “datetime” column in the table.
• Ingestion time: Tables are partitioned based on the timestamp recorded when BigQuery ingested the data.
• Integer range: Tables are partitioned based on an integer column.

Partitions are enabled when the table is created, as in the example below.  A great tip is to always include the partition filter as shown on the left-hand side of the query.

Clustering
Clustering can be created on top of partitioned tables by applying the fields that are likely to be used for filtering. When you create a clustered table in BigQuery, the table data is automatically organized based on the contents of one or more of the columns in the table’s schema. The columns you specify are then used to colocate related data.

Clustering can improve the performance of certain query types — for example, queries that use filter clauses or that aggregate data. It makes a lot of sense to use them for large tables such as ACDOCA, the table for accounting documents in SAP S/4HANA. In this case, the timestamp could be used for partitioning, and common filtering fields such as the ledger, company code, and fiscal year could be used to define the clusters.

A great feature is that BigQuery will also periodically recluster the data automatically.

Materialized views

In BigQuery, materialized views are precomputed views that periodically cache the results of a query for better performance and efficiency. BigQuery uses precomputed results from materialized views and, whenever possible, reads only the delta changes from the base table to compute up-to-date results quickly. Materialized views can be queried directly or can be used by the BigQuery optimizer to process queries to the base table.

Queries that use materialized views are generally completed faster and consume fewer resources than queries that retrieve the same data only from the base table. If workload performance is an issue, materialized views can significantly improve the performance of workloads that have common and repeated queries. While materialized views currently only support single tables, they are very useful common and frequent aggregations like stock levels or order fulfillment.

Further tips on performance optimization while creating select statements can be found in the documentation for optimizing query computation.

Deployment pipeline and security

For most of the work you’ll do in BigQuery, you’ll normally have at least two delivery pipelines running — one for the actual objects in BigQuery and the other to keep the data staging, transforming, and updated as intended within the change-data-capture flows. Note that you can use most existing tools for your Continuous Integration / Continuous Deployment (CI/CD) pipeline — one of the benefits of using an open system like BigQuery. But, if your organization is new to CI/CD pipelines, this is a great opportunity to gradually gain experience. A good place to start is to read our guide for setting up a CI/CD pipeline for your data-processing workflow.  

When it comes to access and security, most end-users will only have access to the final version of the BigQuery views. While row and column-level security can be applied, as in the SAP source system, separation of concerns can be taken to the next level by splitting your data across different Google Cloud projects and BigQuery datasets. While it’s easy to replicate data and structures across your datasets, it’s a good idea to define the requirements and naming conventions early in the design process so you set it up properly from the start. 

Start driving faster and more insightful analytics

The best piece of advice we can give you is this: Try it yourself. Anyone with SQL knowledge can get started using the free BigQuery tier. New customers get $300 in free credits to spend on Google Cloud during the first 90 days. All customers get 10 GB storage and up to 1 TB queries/month, completely free of charge. In addition to discovering the massive processing capabilities, embedded machine learning, multiple integration tools, and cost benefits, you’ll soon discover how BigQuery can simplify your analytics tasks. 

If you need additional assistance, our Google Cloud Professional Services Organization (PSO) and Customer Engineers will be happy to help show you the best path forward for your organization. For anything else, contact us at cloud.google.com/contact.

Road construction is booming in India. A recent report prepared by the India Brand Equity Foundation—a trust established by the Department of Commerce—pointed out that in FY 2019 alone, the country added 10,855 kilometers of highways to a road network that spans 5.89 million kilometers. This network is the second largest in the world and transports 90% of passenger traffic and 64.5% of all goods in the country.

The Indian Government has also earmarked road construction as key to plans to increase the nation’s GDP to $5 trillion in coming years, targeting road construction worth $212.8 billion in the two years from April 2020.

G R Infraprojects Limited is well positioned to support the government’s program. The business, which started as a contractor building roads in rural villages in India, now specializes in road engineering, procurement, and construction (EPC), a model whereby private construction firms build roads funded by the government.

The business now undertakes the processing of bitumen, manufacture of thermoplastic road-marking paint and road signage, and fabrication and galvanizing road-crash barriers. Its in-house integration model includes a design and engineering team, as well as manufacturing facilities in Rajasthan, Assam, and Gujarat.

The business recently expanded into rail—another area expected to benefit from extensive government investment—with its competencies including earthworks, materials supply, track lining, and bridge construction.

In this environment—and despite the economic impact of the coronavirus pandemic—G R Infraprojects Limited aims to substantially increase turnover and manpower over the next five years.

Best-in-class infrastructure key to success

Digital transformation is key to enabling growth while best-in-class IT infrastructure is one of the foundations on which the business seeks to build success.

G R Infraprojects Limited’s digital initiatives include deployment of a new document management system and corporate systems that enable remote monitoring, live tracking, effective real-time communication, and efficient data management.

Providing a scalable, reliable cost-effective infrastructure

But most important of all is providing a scalable, reliable, and cost-effective infrastructure to support a business-critical SAP enterprise resource planning system. Over the last few years, versions of SAP have enabled the organization to digitize processes and seamlessly run business-critical functions such as inventory management and finance.

G R Infraprojects Limited initially went live with SAP ECC6.0, with a few hundred team members using the system for business-critical tasks such as tracking stock level and movement and generating financial statements and reports for review and action.

“Google Cloud is a very big brand, so we were easily able to secure the trust from our executive and business teams to run an important system such as SAP S/4HANA on the platform.”—Sachin Kumar Agarwal, Head, Transformation, G R Infraprojects Limited

Lowering maintenance costs

However, as G R Infraprojects Limited grew, projects proliferated, and new markets emerged, the business elected to move to the cloud from an on-premises infrastructure. “We wanted to move because there were so many maintenance costs in on-premises solutions and cloud provided convenience to IT and the broader organization,” explains Sachin Kumar Agarwal, Head, Transformation at G R Infraprojects Limited.

The business also wanted to move to SAP S/4HANA to take advantage of features such as AI, advanced analytics, and machine learning to transform business processes. The system runs on the HANA database, an in-memory database with fast processing speeds and a simplified data model.

G R Infraprojects Limited selected Google Cloud to run SAP S/4HANA because, Sachin says, it is “much better than any other platform,” incorporates a wide range of features, and meets uptime requirements. The cloud service could also scale to support forecast growth without a sharp increase in cost.

Furthermore, Sachin adds, “Google Cloud is a very big brand, so we were easily able to secure the trust from our executive and business teams to run an important system such as SAP S/4HANA on the platform.”

“With Google Cloud, our speed and availability are controlled and optimized day by day. With such a scalable and dynamic platform, we are very happy with the performance.”—Sachin Kumar Agarwal, Head, Transformation, G R Infraprojects Limited

Successful transition with Infrabeat

G R Infraprojects Limited completed the project with assistance from partner InfraBeat over three months and SAP S/4HANA on Google Cloud went live mid-2019. “Our dedicated SAP team worked closely with Infrabeat to deliver the project successfully,” says Sachin. “We needed an experienced partner to assist with the implementation process and Infrabeat performed that role admirably. Both teams supported each other and worked to plan to deliver a great result.”

SAP S/4HANA runs on an infrastructure comprising virtual machine instances delivered through Compute Engine, Cloud Storage, and Cloud NAT to enable the secure transmission and receipt of packets to and from the internet.

G R Infraprojects Limited estimates the cost of running SAP S/4 HANA in Google Cloud is significantly lower than on alternative infrastructure options—freeing up budget for other business priorities.

In addition, moving SAP S/4 HANA to infrastructure as a service through Google Cloud has eliminated the need to assign internal team members to infrastructure management, allowing them instead to focus on higher-value activities.

Google Cloud also incorporates the security needed to protect the data and processes of SAP S/4 HANA from intrusion or disruption and ensure the uptime and continuity required of a business-critical system.

Optimized speed and availability

G R Infraprojects Limited’s decision to run SAP S/4 HANA on Google Cloud is delivering benefits on a daily basis. “With Google Cloud, our speed and availability are controlled and optimized day by day,” says Sachin. “We are very happy with the performance.”

Success with SAP S/4HANA has helped the business decide to move its remaining apps and data to the cloud when its on-premises servers and other equipment reach end of life. G R Infraprojects Limited is already running Active Directory in Google Cloud and Sachin says the cloud platform’s “fast and excellent services” made the decision easy.

“There are definitely instances of various upgrades of our systems and within the organization, and as we talk about our application and mobility requirements, we see Google Cloud playing a crucial role.”—Sachin Kumar Agarwal, Head, Transformation, G R Infraprojects Limited

Adding value

As G R Infraprojects Limited grows, Sachin adds, the business expects Google Cloud to continue to add value. “There are definitely instances of various upgrades of our systems and within the organization, and as we talk about our application and mobility requirements, we see Google Cloud playing a crucial role.”

For many enterprises, the venerable mainframe is home to decades’ worth of data about the company’s customers, processes and operations. And it goes without saying that the business would like access to that mainframe data — to report on it, to analyze it with big data analysis tools, or to use it as the basis of new machine learning and artificial intelligence initiatives.

At Google Cloud, we are eager to work with organizations to help them transform their mainframe assets for the cloud era. Of course, we can help them modernize their mainframe applications by migrating them to the cloud. At the same time, working with partners and customers, we’ve developed another, more lightweight approach that can help them start to leverage the cloud for their mainframe assets much more quickly than performing a full-fledged migration. We call this approach data-first digitization.   

In this rapidly evolving digital ecosystem, it’s imperative to understand the difference between ‘modernization’ and ‘digitization.’ With modernization you start with the current state and look forward, and rely on mainframe application migration approaches such as rehosting (emulation), refactoring (automated code transformation), reengineering — or simply replacing a custom application with a commercial package. With digitization, you start with the future state that you want to achieve, and work back to what is required to get there.

This data-first digitization approach includes a mainframe data-first integration framework comprising in-house and partner products and tools to migrate heterogeneous data sources from the mainframe to Google Cloud Storage. Once mainframe data has been copied to Cloud Storage, it can then be integrated and leveraged by Google Cloud tools such as BigQuery, AI and machine learning prodcuts  and Smart and Stream analytics platforms. The integration framework covers both bulk batch data transfers and real-time data replication (change data capture).

Data-first digitization is based on the tenet that ‘applications are transient, data is permanent.’ By bringing data first to Google Cloud instead of traditional ways of modernizing applications (for example, with Gartner’s 7 options to Modernize), this allows organizations to leapfrog to new business models, use cases and innovative ways to serve end customers. For example:

• Making decisions with smart and stream analytics platforms and AI/ML engines. These tools need data to make decisions. Google is a pioneer in extracting information and value from the raw structured and unstructured data, and this approach opens up mainframe data for use by BigQuery and AI/ML models. 
• Building new reporting applications. With access to mainframe data, you can use Google cloud products like Looker and Appsheet to build net-new reporting applications, expediting the process of retiring mainframe reporting applications, and accelerating your overall transformation.

In our experience, taking a data-first digitization approach to your mainframe offers a number of benefits:

1. Faster time-to-business: Because data-first modernization is built on existing products, the implementation cycle is much shorter.
2. Less capital investment: You spend your time integrating products, not developing applications.
3. Minimized risk: Data-first integrates with existing, proven and reliable Google Cloud products.
4. Faster overall mainframe transformation: When you shift your modernization center of gravity from the application to the data, you look at mainframe applications from a business perspective instead of just “keeping the lights on.” As a result, only the most business-critical applications are modernized and many support applications can be decommissioned, accelerating your transformation journey. 

Taking a data-first approach to digitization is still relatively new, but we’re heartened by customers’ early successes. Watch this space for additional insights, reference architectures and technical white papers around data-first. And if you think this approach may be right for you, reach out to mainframe@google.com.

Learn more:

• Liberating your mainframe data with Confluent and Google Cloud
• Beyond mainframe modernization: The art of possibilities

The typical smart factory is said to produce around 5 petabytes of data per week. That’s equivalent to 5 million gigabytes, or roughly 20,000 smartphones.

Managing such vast amounts of data in one facility, let alone a global organization, would be challenging enough. Doing so on the factory floor, in near-real-time, to drive insights, enhancements, and particularly safety, is a big dream for leading manufacturers. And for many, it’s becoming a reality, thanks to the possibilities unlocked with edge computing.

Edge computing brings computation, connectivity, and data closer to where the information is generated, enabling better data control, faster insights, and actions. Taking advantage of edge computing requires the hardware and software to collect, process, and analyze data locally to enable better decisions and improve operations.

At Hannover Messe 2022, Intel and Google Cloud will demonstrate a new technology implementation that combines the latest generation of Intel processors with Google Cloud’s data and AI expertise to optimize production operations from edge to cloud. This proof-of-concept project is powered by the Edge Insights for Industrial platform (EII), an industry-specific platform from Intel; and a pair of Google Cloud solutions: Anthos, Google Cloud’s managed applications platform, and the newly-launched Manufacturing Data Engine.

Edge computing exploits the untapped gold mine of data sitting on-site and is expected to grow rapidly. The Linux Foundation’s “2021 State of the Edge” predicts that by 2025, edge-related devices will produce roughly 90 zettabytes of data. Edge computing can help provide greater data privacy and security, and can accomodate the reduced bandwidth needs between local storage and the cloud.

Imagine a world in which the power of big data and AI-driven data analytics is available at the point where the data is gathered to inform, make, and implement decisions in near real-time.

This could be anywhere on the factory floor, from a welding station to a painting operation or more. Data would be collected by monitoring robotic welders, for example, and analyzed by industrial PCs (IPCs) located at the factory edge. These edge IPCs would detect when the welders are starting to go off spec, predicting increased defect rates even before they appear, and adding preventive maintenance to correct the errors without any direct intervention. Real time, predictive analytics using AI could substantially prevent defects before they happen. Or the same IPCs could use digital cameras for visual inspection to monitor and identify defects in real-time, allowing them to be addressed quickly.

Edge computing has powerful potential applications in assisting with data gathering, processing, storage and analysis in many manufacturing sectors, including automotive, semiconductor and electronics manufacturing, and consumer packaged goods. Whether modeling and analysis is done and stored locally or in the cloud, or is predictive, simultaneous, or lagged, technology providers are aligning to meet these needs. This is the new world of edge computing.

The joint Intel and Google Cloud proof of concept aims to extend the Google Cloud capabilities and solutions to the edge. Intel’s full breadth of industrial solutions, hardware and software, are coming together in this edge-ready solution, encompassing Google Cloud industry-leading tools. The concept shortens the time to insights, streamlining data analytics and AI at the edge.

The Intel-Google Cloud proof of concept demonstrates how manufacturers can gather and analyze data from over 250 factory devices using Manufacturing Connect from Google Cloud, providing a powerful platform to run data ingestion and AI analytics at the edge.

In this demonstration in Hannover, Intel and Google Cloud show how manufacturers can capture time-series data from robotic welders to inspect welding quality and show how predictive analytics can benefit the factory operators. In addition, the video and image data is captured from a factory camera to show how visual inspection can highlight anomalies on plastic chips with model scoring. The demo also features zero-touch device onboarding using FIDO Device Onboard (FDO) to illustrate the ease with which additional computers could be added to the existing Anthos cluster.

By combining Google Cloud’s expertise in data, AI/ML and Intel’s Edge Insight’s for Industrial platform that was optimized to run on Google Anthos, manufacturers can run and manage their containerized applications at the edge, in on-premise data center, or in public clouds using an efficient and secure connection to the Manufacturing Data Engine from Google Cloud. It forges a complete edge-to-cloud solution.

Simplified device onboarding is available using Fido Device Onboard (FDO)—an open IoT protocol that brings fast, secure, and scalable zero-touch onboarding of new IoT devices to the edge. FDO allows factories to easily deploy automation and intelligence in their environment without introducing complexity into their OT infrastructure.

The Intel-Google Cloud implementation can analyze that data using localized Intel or third-party AI and machine learning algorithms. Applications can be layered on the Intel hardware and Anthos ecosystem, allowing customized data monitoring and ingestion, data management and storage, modeling, and analytics. This joint PoC facilitates and support improved decision making and operations, whether automated or triggered by the engineers on the front lines.

Intel collaborates with a vibrant ecosystem of leading hardware partners to develop solutions for the industrial market by using the latest generation of Intel processors. These processors can run data intensive workloads at the edge with ease.

Putting data and AI directly into the hands of manufacturing engineers can improve quality inspection loops, customer satisfaction, and ultimately the bottom line.

The new manufacturing solutions will be demonstrated in person for the first time at Hannover Messe 2022, May 30–June 2, 2022. Visit us at Stand E68, Hall 004, or schedule a meeting for an onsite demonstration with our experts.