Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Model semantik dalam kapasitas Premium dengan titik akhir XMLA yang diaktifkan untuk operasi baca/tulis memungkinkan penyegaran yang lebih canggih, manajemen partisi, dan penyebaran metadata hanya melalui alat, pembuatan skrip, dan dukungan API. Selain itu, operasi refresh melalui titik akhir XMLA tidak terbatas pada 48 refresh per hari, dan batas waktu refresh terjadwal tidak diberlakukan.
Partitions
Partisi tabel model semantik tidak terlihat dan tidak dapat dikelola dengan menggunakan Power BI Desktop atau layanan Power BI. Untuk model di ruang kerja yang ditetapkan ke kapasitas Premium, partisi dapat dikelola melalui titik akhir XMLA. Anda dapat menggunakan alat seperti SQL Server Management Studio (SSMS) atau Editor Tabular sumber terbuka untuk mengelola partisi melalui pembuatan skrip dengan Tabular Model Scripting Language (TMSL), dan secara terprogram dengan Model Objek Tabular (TOM).
Saat Anda pertama kali menerbitkan model ke layanan Power BI, setiap tabel dalam model baru memiliki satu partisi. Untuk tabel tanpa kebijakan refresh bertahap, bahwa satu partisi berisi semua baris data untuk tabel tersebut, kecuali filter diterapkan. Untuk tabel dengan kebijakan refresh bertahap, satu partisi awal hanya ada karena Power BI belum menerapkan kebijakan. Anda mengonfigurasi partisi awal di Power BI Desktop saat menentukan filter rentang tanggal/waktu untuk tabel Anda berdasarkan RangeStart parameter dan RangeEnd , dan filter lain yang diterapkan di Editor Power Query. Partisi awal ini hanya berisi baris data yang memenuhi kriteria filter Anda.
Saat Anda melakukan operasi refresh pertama , tabel tanpa kebijakan refresh bertahap me-refresh semua baris yang terkandung dalam partisi tunggal default tabel tersebut. Untuk tabel dengan kebijakan refresh bertahap, refresh dan partisi historis secara otomatis dibuat dan baris dimuat ke dalamnya sesuai dengan tanggal/waktu untuk setiap baris. Jika kebijakan penyegaran bertahap menyertakan pengambilan data secara waktu nyata, Power BI juga menambahkan partisi DirectQuery pada tabel.
Penting
Saat Anda menggunakan refresh bertahap dengan data real-time (mode hibrid), tabel yang terkait dengan tabel hybrid harus menggunakan mode penyimpanan Dual untuk menghindari penalti kinerja. Selain itu, caching visual dapat menunda pembaruan langsung hingga visual melakukan kueri ulang data. Untuk informasi selengkapnya, lihat Pemecahan Masalah Penyegaran Bertahap dan Data Waktu Nyata.
Operasi refresh pertama ini dapat memakan waktu cukup lama tergantung pada jumlah data yang perlu dimuat dari sumber data. Kompleksitas model juga dapat menjadi faktor yang signifikan karena operasi refresh harus melakukan lebih banyak pemrosesan dan penghitungan ulang. Operasi ini dapat diinisialisasi dengan sumber daya minimal. Untuk informasi lebih lanjut, lihat Mencegah timeout pada awal refresh penuh.
Partisi dibuat untuk dan dinamai berdasarkan granularitas periode: Tahun, kuartal, bulan, dan hari. Partisi terbaru, yaitu partisi refresh, berisi baris dalam periode pembaruan yang Anda tentukan dalam kebijakan. Partisi historis mengandung baris-baris berdasarkan periode lengkap hingga periode pembaruan. Jika real time diaktifkan, partisi DirectQuery mengambil perubahan data apa pun yang terjadi setelah tanggal akhir periode refresh. Tingkat kehalusan untuk penyegaran dan partisi historis tergantung pada periode penyegaran dan penyimpanan (historis) yang Anda pilih saat menetapkan kebijakan.
Misalnya, jika tanggal hari ini adalah 2 Februari 2021 dan tabel FactInternetSales kami di sumber data berisi baris hingga hari ini. Jika kebijakan kami menentukan untuk menyertakan perubahan langsung, maka refresh baris dalam periode penyegaran yang berlangsung satu hari terakhir, dan menyimpan baris dalam konteks historis selama tiga tahun terakhir. Kemudian dengan operasi refresh pertama, partisi DirectQuery dibuat untuk perubahan di masa mendatang. Partisi impor baru dibuat untuk baris data hari ini, dan partisi historis dibuat untuk data kemarin, periode penuh satu hari, 1 Februari 2021. Partisi historis dibuat untuk periode sebulan penuh sebelumnya (Januari 2021). Partisi historis dibuat untuk periode seluruh tahun sebelumnya (2020). Dan partisi historis untuk periode tahun penuh 2019 dan 2018 dibuat. Tidak ada seluruh partisi kuartal yang dibuat karena pada 2 Februari, kuartal penuh pertama 2021 belum selesai.
Dengan setiap operasi refresh, hanya partisi yang diperbarui untuk periode refresh. Filter tanggal partisi DirectQuery diperbarui untuk menyertakan hanya perubahan yang terjadi setelah periode refresh saat ini. Partisi refresh baru dibuat untuk baris baru dengan tanggal/waktu baru dalam periode refresh yang diperbarui. Baris yang ada dengan tanggal/waktu yang sudah ada dalam partisi yang ada dalam periode refresh di-refresh dengan pembaruan. Baris dengan tanggal/waktu yang lebih lama dari periode penyegaran tidak lagi diperbarui.
Setelah seluruh periode ditutup, partisi digabungkan. Misalnya, jika periode penyegaran satu hari dan periode penyimpanan historis tiga tahun ditentukan dalam kebijakan, pada hari pertama setiap bulan, seluruh partisi harian untuk bulan sebelumnya digabungkan menjadi partisi bulanan. Pada hari pertama kuartal baru, ketiga partisi bulan sebelumnya digabungkan menjadi partisi seperempat. Pada hari pertama tahun baru, keempat partisi kuartal sebelumnya digabungkan menjadi partisi setahun.
Model selalu mempertahankan partisi untuk seluruh periode penyimpanan historis ditambah partisi seluruh periode hingga periode refresh saat ini. Dalam contoh, tiga tahun penuh data historis disimpan dalam partisi untuk 2018, 2019, 2020, dan juga partisi untuk periode bulan 2021Q101, periode hari 2021Q10201, serta partisi untuk periode pembaruan pada hari ini. Karena contoh menyimpan data historis selama tiga tahun, partisi 2018 dipertahankan hingga refresh pertama pada 1 Januari 2022.
Dengan penyegaran inkremental Power BI dan data waktu nyata, layanan Power BI menangani manajemen partisi untuk Anda berdasarkan kebijakan layanan tersebut. Meskipun layanan dapat menangani semua manajemen partisi untuk Anda, dengan menggunakan alat melalui titik akhir XMLA, Anda dapat secara selektif menyegarkan partisi satu per satu, secara berurutan, atau paralel.
Pola Penyegaran Partisi Umum
Saat bekerja dengan operasi titik akhir XMLA, pertimbangkan pola umum ini untuk mengelola operasi refresh:
- Refresh kecil yang sering: Jalankan beberapa operasi refresh kecil yang ditargetkan selama jam kerja menggunakan perintah partisi XMLA atau REST API yang ditingkatkan untuk menjaga data terbaru tetap terkini tanpa memproses seluruh tabel.
-
Backfills historis selektif: Lakukan penyegaran partisi historis yang lebih lengkap atau perbaikan data satu kali di luar jam kerja menggunakan TMSL dengan
applyRefreshPolicy: falseuntuk mengulang periode historis tertentu dan tidak memengaruhi aturan otomatis. - Beban awal bertahap: Untuk periode historis yang besar, pecahkan refresh awal menjadi batch yang lebih kecil dengan memproses partisi secara bertahap untuk menghindari batas waktu dan mengelola konsumsi sumber daya.
Pola-pola ini memungkinkan Anda menyeimbangkan kesegaran data real-time dengan performa sistem dan batasan sumber daya.
Refresh manajemen dengan SQL Server Management Studio
SQL Server Management Studio (SSMS) dapat digunakan untuk melihat dan mengelola partisi yang dibuat oleh penerapan kebijakan refresh bertahap. Dengan menggunakan SSMS, Anda dapat, misalnya, menyegarkan partisi historis tertentu yang tidak termasuk dalam periode penyegaran bertahap untuk melakukan pembaruan mundur tanpa harus menyegarkan semua data historis. SSMS juga dapat digunakan saat bootstrapping untuk memuat data historis untuk model besar dengan menambahkan/menyegarkan partisi historis secara bertahap dalam batch.
Mengambil alih perilaku refresh inkremental
Dengan SQL Server Management Studio, Anda juga memiliki kontrol lebih atas cara memanggil refresh dengan menggunakan Bahasa Skrip Model Tabular dan Model Objek Tabular. Misalnya, di SQL Server Management Studio, di Object Explorer, klik kanan tabel lalu pilih opsi menu Tabel Proses , lalu pilih tombol Skrip untuk menghasilkan perintah refresh TMSL.
Parameter ini dapat digunakan dengan perintah refresh TMSL untuk mengambil alih perilaku refresh inkremental default:
applyRefreshPolicy. Jika tabel memiliki kebijakan refresh bertahap yang ditentukan,
applyRefreshPolicymenentukan apakah kebijakan diterapkan atau tidak. Jika kebijakan tidak diterapkan, proses operasi penuh membuat definisi partisi tidak berubah dan semua partisi dalam tabel sepenuhnya disegarkan. Nilai defaultnya adalah true.effectiveDate. Jika kebijakan refresh bertahap diterapkan, perlu mengetahui tanggal saat ini untuk menentukan rentang jendela bergulir untuk refresh bertahap dan periode historis. Parameter
effectiveDatememungkinkan Anda mengambil alih tanggal saat ini. Parameter ini berguna untuk pengujian, demo, dan skenario bisnis di mana data disegarkan secara bertahap hingga tanggal di masa lalu atau di masa mendatang, misalnya, anggaran di masa mendatang. Nilai defaultnya adalah tanggal saat ini.
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
Untuk mempelajari selengkapnya tentang mengesampingkan perilaku refresh inkremental default dengan TMSL, lihat Perintah refresh.
Mengelola kebijakan dengan Editor Tabular
Selain SSMS, Anda dapat menggunakan Editor Tabular untuk membuat dan memodifikasi kebijakan refresh bertahap secara langsung terhadap model semantik melalui titik akhir XMLA. Metode ini memungkinkan Anda menyesuaikan pengaturan kebijakan—seperti periode refresh, periode historis, dan ekspresi sumber—tanpa perlu menerbitkan ulang model dari Power BI Desktop. Editor Tabular juga dapat digunakan untuk menerapkan kebijakan refresh ke tabel yang ada dan mengelola RangeStart dan RangeEnd ekspresi parameter. Untuk informasi selengkapnya, lihat Refresh inkremental di dokumentasi Editor Tabular.
Pembaruan orkestrasi dan otomatisasi
Selain menggunakan SSMS, TMSL, dan TOM untuk mengelola refresh melalui endpoint XMLA. Anda juga dapat mengatur operasi refresh model semantik menggunakan Power BI REST API. API refresh yang disempurnakan menyediakan lebih banyak kemampuan termasuk refresh tingkat tabel dan tingkat partisi, logika coba lagi, pembatalan, dan manajemen batas waktu kustom. Pendekatan ini berguna untuk mengintegrasikan operasi refresh ke dalam alur kerja otomatis dan alur CI/CD. Untuk panduan mendetail, lihat Refresh yang disempurnakan dengan Power BI REST API.
Memastikan performa optimal
Dengan setiap operasi refresh, layanan Power BI mungkin mengirim kueri inisialisasi ke sumber data untuk setiap partisi refresh bertahap. Anda mungkin dapat meningkatkan performa refresh bertambah bertahap dengan mengurangi jumlah kueri inisialisasi dengan memastikan konfigurasi berikut:
- Tabel yang Anda konfigurasikan refresh inkrementalnya harus mendapatkan data dari satu sumber data. Jika tabel mendapatkan data dari lebih dari satu sumber data, jumlah kueri yang dikirim oleh layanan untuk setiap operasi refresh dikalikan dengan jumlah sumber data, berpotensi mengurangi performa refresh. Pastikan kueri untuk tabel refresh inkremental adalah untuk satu sumber data.
- Untuk solusi dengan refresh bertahap partisi impor dan data real time dengan Direct Query, semua partisi harus mengkueri data dari satu sumber data.
- Jika persyaratan keamanan Anda mengizinkan, atur pengaturan Tingkat privasi sumber data ke Organisasi atau Publik. Secara default, tingkat privasinya adalah Privat. Namun, tingkat ini dapat mencegah data ditukar dengan sumber cloud lainnya. Untuk mengatur tingkat privasi, pilih menu Opsi lainnya, lalu pilih Pengaturan>Kredensial sumber data>Edit kredensial>Pengaturan tingkat privasi untuk sumber data ini. Jika Tingkat Privasi diatur dalam model Power BI Desktop sebelum diterbitkan ke layanan, pengaturan ini tidak akan ditransfer saat Anda mempublikasikannya. Anda masih harus mengaturnya dalam pengaturan model semantik dalam layanan. Untuk mempelajari selengkapnya, lihat Tingkat privasi.
- Jika menggunakan Gateway Data Lokal, pastikan Anda menggunakan versi 3000.77.3 atau yang lebih tinggi.
Mencegah batas waktu pada refresh penuh awal
Setelah Anda menerbitkan ke layanan Power BI, operasi penyegaran penuh awal untuk model tersebut membuat partisi untuk tabel yang mengalami penyegaran bertahap, serta memuat dan memproses data historis untuk seluruh periode yang ditentukan dalam kebijakan penyegaran bertahap. Untuk beberapa model yang memuat dan memproses data dalam jumlah besar, jumlah waktu yang diperlukan operasi refresh awal dapat melebihi batas waktu refresh yang diberlakukan oleh layanan atau batas waktu kueri yang diberlakukan oleh sumber data.
Bootstrapping operasi penyegaran awal memungkinkan layanan untuk membuat objek partisi untuk tabel penyegaran bertahap, tetapi tidak memuat dan memproses data historis ke dalam partisi mana pun. SSMS kemudian digunakan untuk memproses partisi secara selektif. Tergantung pada jumlah data yang akan dimuat untuk setiap partisi, Anda dapat memproses setiap partisi secara berurutan atau dalam batch kecil. Metode ini mengurangi potensi satu atau beberapa partisi tersebut menyebabkan timeout. Metode berikut berfungsi untuk sumber data apa pun.
Terapkan Kebijakan Refresh
Alat sumber terbuka Tabular Editor 2 menyediakan cara mudah untuk memulai operasi penyegaran awal. Setelah menerbitkan model dengan kebijakan penyegaran inkremental yang ditentukan untuk model tersebut dari Power BI Desktop ke layanan, sambungkan ke model dengan menggunakan titik akhir XMLA dalam mode Baca/Tulis. Jalankan Terapkan Kebijakan Refresh pada tabel refresh bertahap. Hanya dengan kebijakan yang diterapkan, partisi dibuat tetapi tidak ada data yang dimuat ke dalamnya. Kemudian sambungkan dengan SSMS untuk me-refresh partisi secara berurutan atau dalam batch untuk memuat dan memproses data. Untuk informasi selengkapnya, lihat Refresh inkremental di dokumentasi editor Tabular.
Filter Power Query untuk partisi kosong
Sebelum menerbitkan model ke layanan, di Editor Power Query, tambahkan filter lain ke ProductKey kolom yang memfilter nilai apa pun selain 0, secara efektif atau memfilter semua data dari tabel FactInternetSales .
Setelah memilih Tutup & Terapkan di Editor Power Query, tentukan kebijakan refresh bertahap, dan simpan model, model diterbitkan ke layanan. Melalui layanan, operasi penyegaran awal dijalankan pada model. Partisi untuk tabel FactInternetSales dibuat sesuai dengan kebijakan, tetapi tidak ada data yang dimuat dan diproses karena semua data difilter.
Setelah operasi refresh awal selesai, kembali ke Editor Power Query, filter lain pada ProductKey kolom dihapus. Setelah memilih Tutup & Terapkan di Editor Power Query dan menyimpan model, model tidak diterbitkan lagi. Jika model diterbitkan kembali, itu akan menimpa pengaturan kebijakan penyegaran bertahap dan mengharuskan penyegaran penuh pada model saat operasi penyegaran berikutnya dilakukan dari layanan. Sebagai gantinya, lakukan penyebaran metadata hanya dengan menggunakan Toolkit Manajemen Siklus Hidup Aplikasi (ALM) yang menghapus filter pada ProductKey kolom dari model. SSMS kemudian dapat digunakan untuk memproses partisi secara selektif. Ketika semua partisi sepenuhnya diproses, yang harus menyertakan penghitungan ulang proses pada semua partisi menggunakan SSMS, operasi refresh berikutnya pada model dari layanan hanya akan melakukan refresh pada partisi refresh inkremental.
Petunjuk / Saran
Pastikan untuk melihat video, blog, dan lainnya yang disediakan oleh komunitas pakar BI Power BI.
Untuk mempelajari selengkapnya tentang pemrosesan tabel dan partisi dari SQL Server Management Studio, lihat Memproses database, tabel, atau partisi (Analysis Services). Untuk mempelajari selengkapnya tentang memproses model, tabel, dan partisi dengan menggunakan TMSL, lihat Perintah refresh (TMSL).
Kueri kustom untuk mendeteksi perubahan data
TMSL dan TOM dapat digunakan untuk mengambil alih perilaku perubahan data yang terdeteksi. Metode ini dapat digunakan untuk menghindari bertahannya kolom pembaruan terakhir di cache dalam memori. Ini juga dapat mengaktifkan skenario di mana konfigurasi atau tabel instruksi disiapkan dengan proses ekstraksi, transformasi, dan pemuatan (ETL). Memungkinkan Anda untuk menandai hanya partisi yang perlu di-refresh. Metode ini dapat membuat proses refresh inkremental yang lebih efisien di mana hanya periode yang diperlukan yang disegarkan, tidak peduli berapa lama pembaruan data yang berlangsung.
pollingExpression dimaksudkan untuk menjadi ekspresi M yang ringan atau nama kueri M lainnya. Ini harus mengembalikan nilai skalar dan dijalankan untuk setiap partisi. Jika nilai yang dikembalikan berbeda dari nilai yang saat refresh inkremental terakhir terjadi, partisi itu ditandai untuk diproses secara penuh.
Contoh berikut mencakup seluruh 120 bulan dalam masa periode historis untuk perubahan yang tercatat. Menentukan 120 bulan alih-alih 10 tahun berarti pemadatan data mungkin tidak seefisien itu. Namun, itu menghindari kebutuhan untuk menyegarkan seluruh tahun historis, yang akan lebih mahal ketika sebulan akan cukup untuk perubahan tanggal mundur.
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
Petunjuk / Saran
Pastikan untuk melihat video, blog, dan lainnya yang disediakan oleh komunitas pakar BI Power BI.
Penyebaran metadata saja
Saat Anda menerbitkan versi baru file .pbix dari Power BI Desktop ke ruang kerja. Anda melihat perintah berikut untuk mengganti model yang ada, jika model dengan nama yang sama sudah ada.
Dalam beberapa kasus, mungkin Anda tidak ingin mengganti model, terutama dalam konteks penyegaran bertahap. Model di Power BI Desktop bisa jauh lebih kecil dari yang ada di layanan Power BI. Jika model dalam layanan Power BI memiliki kebijakan refresh bertahap yang diterapkan, Anda mungkin kehilangan beberapa tahun data historis jika model diganti. Menyegarkan semua data historis dapat memakan waktu berjam-jam dan mengakibatkan waktu henti sistem bagi pengguna.
Sebaliknya, lebih baik melakukan penyebaran metadata saja, yang memungkinkan penyebaran objek baru tanpa kehilangan data historis. Misalnya, jika Anda hanya menambahkan beberapa langkah, Anda hanya dapat menyebarkan langkah-langkah baru tanpa perlu merefresh data, menghemat waktu.
Untuk ruang kerja yang ditetapkan ke kapasitas Premium yang dikonfigurasi untuk baca/tulis titik akhir XMLA, alat yang kompatibel memungkinkan hanya penyebaran metadata. Misalnya, ALM Toolkit adalah alat diff skema untuk model Power BI dan dapat digunakan untuk melakukan penyebaran metadata saja.
Unduh dan instal versi terbaru ALM Toolkit dari repositori Git Analysis Services. Panduan langkah demi langkah tentang menggunakan ALM Toolkit tidak disertakan dalam dokumentasi Microsoft. Tautan dokumentasi Toolkit ALM dan informasi tentang dukungan tersedia di pita Bantuan . Untuk melakukan penyebaran metadata saja, lakukan perbandingan dan pilih instans Power BI Desktop yang sedang berjalan sebagai sumbernya, dan model yang ada di layanan Power BI sebagai target. Pertimbangkan perbedaan yang ditampilkan dan lewati pembaruan tabel dengan partisi refresh bertahap atau gunakan dialog Opsi untuk mempertahankan partisi untuk pembaruan tabel. Validasi pilihan untuk memastikan integritas model target lalu perbarui.
Menambahkan kebijakan refresh inkremental dan data real-time secara terprogram
Anda juga dapat menggunakan TMSL dan TOM untuk menambahkan kebijakan refresh inkremental ke model yang ada melalui titik akhir XMLA.
Nota
Untuk menghindari masalah kompatibilitas, pastikan Anda menggunakan versi terbaru pustaka klien Analysis Services. Misalnya, untuk bekerja dengan kebijakan Hibrid, versinya harus 19.27.1.8 atau yang lebih tinggi.
Proses ini mencakup langkah-langkah berikut:
Pastikan model target memiliki tingkat kompatibilitas minimum yang diperlukan. Di SSMS, klik kanan [nama model]>Tingkat Kompatibilitas>. Untuk meningkatkan tingkat kompatibilitas, gunakan skrip TMSL createOrReplace atau periksa kode sampel TOM berikut misalnya.
a. Import policy - 1550 b. Hybrid policy - 1565Tambahkan parameter
RangeStartdanRangeEndke ekspresi model. Jika perlu, tambahkan juga fungsi untuk mengonversi nilai Tanggal/Waktu ke kunci tanggal.Tentukan sebuah objek
RefreshPolicydengan pengarsipan yang diinginkan (jendela bergulir) dan periode pemutakhiran inkremental serta ekspresi sumber daya yang menyaring tabel target berdasarkan parameterRangeStartdanRangeEnd. Atur mode kebijakan refresh ke Impor atau Hibrid tergantung pada persyaratan data real time Anda. Hibrid menyebabkan Power BI menambahkan partisi DirectQuery ke tabel untuk mengambil perubahan terbaru dari sumber data yang terjadi setelah waktu refresh terakhir.Tambahkan kebijakan refresh ke tabel dan lakukan refresh penuh sehingga Power BI mempartisi tabel sesuai dengan kebutuhan Anda.
Sampel kode berikut menunjukkan cara melakukan langkah-langkah sebelumnya dengan menggunakan TOM. Jika Anda ingin menggunakan sampel ini apa adanya, Anda harus memiliki salinan untuk database AdventureWorksDW dan mengimpor tabel FactInternetSales ke dalam model. Sampel kode mengasumsikan bahwa RangeStart parameter dan RangeEnd dan DateKey fungsi tidak ada dalam model. Cukup impor tabel FactInternetSales dan terbitkan model ke ruang kerja di Power BI Premium. Kemudian perbarui workspaceUrl sehingga sampel kode dapat tersambung ke model Anda. Perbarui baris kode lagi seperlunya.
using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
class Program
{
static string workspaceUrl = "<Enter your Workspace URL here>";
static string databaseName = "AdventureWorks";
static string tableName = "FactInternetSales";
static void Main(string[] args)
{
using (var server = new TOM.Server())
{
// Connect to the dataset.
server.Connect(workspaceUrl);
TOM.Database database = server.Databases.FindByName(databaseName);
if (database == null)
{
throw new ApplicationException("Database cannot be found!");
}
if(database.CompatibilityLevel < 1565)
{
database.CompatibilityLevel = 1565;
database.Update();
}
TOM.Model model = database.Model;
// Add RangeStart, RangeEnd, and DateKey function.
model.Expressions.Add(new TOM.NamedExpression {
Name = "RangeStart",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "RangeEnd",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "DateKey",
Kind = TOM.ExpressionKind.M,
Expression =
"let\n" +
" Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
"in\n" +
" Source"
});
// Apply a RefreshPolicy with Real-Time to the target table.
TOM.Table salesTable = model.Tables[tableName];
TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
{
Mode = TOM.RefreshPolicyMode.Hybrid,
IncrementalPeriodsOffset = -1,
RollingWindowPeriods = 1,
RollingWindowGranularity = TOM.RefreshGranularityType.Year,
IncrementalPeriods = 1,
IncrementalGranularity = TOM.RefreshGranularityType.Day,
SourceExpression =
"let\n" +
" Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
" dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
" #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
"in\n" +
" #\"Filtered Rows\""
};
salesTable.RefreshPolicy = hybridPolicy;
model.RequestRefresh(TOM.RefreshType.Full);
model.SaveChanges();
}
Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
Console.ReadLine();
}
}
}