Відео

Hi Shawn, yes, the DAGs should populate the tables. You can take the SQL files and schedule them with any other scheduler, including dataform. It doesn't have to be Composer, but something needs to run those SQL statements periodically for the tables to refresh. That's assuming you deleted the reporting dataset before re-deploying after changing from view to table. Also, depending on the sequence, you may also want to schedule some SQLs to run only after a specific dependency has been successful. This is a manual modification for the Composer DAGs too.

@@LuciaSubatinGreat thanks for your quick response, appreciate it.

Hi, thanks for watching! Yes, the assumption for SAP is that data is already replicated either in RAW with the timestamp and operation flag, or in CDC with merge. There's no specific choice of tool, as long as the tables are landed with the same field names and formats as in the original tables in SAP ECC or S/4 HANA.

A lot has changed in a year, so we removed this video from the README. Hierarchies can now be flattened with a newly released set of scripts you'll find here: github.com/GoogleCloudPlatform/cortex-reporting/tree/b05a3345d55d5e196d8d636daf0c81541d0604e7/local_k9 The good thing about this new approach is it doesn't require configuration. If you want to learn exactly when this changed, I'd recommend going to the release notes. There's a new playlist that will be linked as soon as it's complete here, but maybe it helps: ua-cam.com/video/n1d654fkPjY/v-deo.html

@@LuciaSubatin Thank you. I was able to actually check the old tags. and project contents. There is reference to sets.yaml in the latest readme too. That was the confusion. I will go through your recommended document,

Hi Shawn, thanks! Hopefully you'll find this helpful: github.com/GoogleCloudPlatform/cortex-data-foundation/blob/main/docs/upgrade_recommendations/upgrade_recommendations.md It explains how to prepare to merge changes as they are released.

Hi @mohtalha, the models in Cortex Data Foundation assume the tables will have the same names and formats as in the source. Cortex is agnostic in terms of the replication tool and intently avoids dependencies on transformations or business logic in the source or the replication tool, so customers can choose the tool that works best for them. In other words, as long as the same types and names are there, the models will work, whether you use datasphere or a spreadsheet to move the data around. If you wanted to add more tables and have the CDC generator create the MERGE script for you, all you'd need to do is declare the table in the cdc_settings.yaml and the script will pick the definition up from dd03l. Then you'd need to add your own JOINs or SQLs in the reporting layer if you wanted the deployer to manage them too. I normally do not recommend replicating pre- aggregated models (e.g., ODP extractors or CDS views) unless they are mimicking raw tables and you have no other way. Does that help?

Hi Espartaco, thanks for watching. The procedure is the same, we keep the cloud build backwards compatible always. I would recommend taking a look at the readme to understand the new options and features introduced in 3.0 though. Good luck! 🦄

@@LuciaSubatin Thank you for your quick reply. I will follow your recommendation. On the other hand, Could I have deployed the previous Cortex Version and the Cortex 3.0 in the same project with the same BQ instance? I think so. But, I want to confirm with you if we could have multiple Cortex deployments on the same project.

@@espartacogonzalez7874 Yes, you can multiple deployments per project, just keep an eye on the names of the datasets so they don't overlap. If you are using our test data, I'd recommend deleting raw and CDC before deploying if using the same dataset between releases.

Thanks, Thorsten! You'll find the options in cloud.google.com/solutions/sap/docs/sap-data-integration-guides and a video about one of those options, the BigQuery Direct Connector, here: ua-cam.com/video/IPKcdJ-Xyyc/v-deo.html

Hey! Yes, here: developers.sap.com/tutorials/hxe-database-xs-advanced.html

@@LuciaSubatin Thanks a lot...

For the server-only flavor the official minimum is 8GB. I'd recommend 12gb.

Hi, Chloe! If you are in SPS03, right click on the database module --> modelling actions --> Maintain time data. The wizard will generate tables and their data if they are not present. If you are looking for the same functionality for plain schemata (like the time generation from HANA Studio), you can right click on the connection to, for example, the tenant HXE and choose "Generate Time Data" from the database explorer

You can, however I do not know how to generate the data in the DEPLOYed version.