Recently active topics

Create an Azure SQL Database Scaling packageAn Azure SQL Database Scaling package rescales a database to a different service tier when it runs. Scale up for the load window, and back down for the day.PrerequisitesAn Azure App Registration data provider in the workspace. This is the App Registration whose service principal the package acts as, and it decides which Azure resources you can choose. The principal able to enumerate resource groups in the subscription. This package finds its resource that way, so without this the resource list is empty and the package cannot be completed. The principal needs permission to change the resource, not only to read it. Listing a resource and scaling it are different rights.How it worksYou choose a data provider, then the database to act on, then what to do to it.When the resource list is empty, the editor names the scope it searched, for example No … were found in … this data provider can see. An empty list reflects the service principal's permissi

Create a TimeXtender Classic packageA TimeXtender Classic package runs an execution package from a TimeXtender Classic repository. It lets a Classic estate be orchestrated, and migrated, from the same place as everything else.PrerequisitesA TimeXtender Classic repository reachable either from TimeXtender Cloud or through a gateway. An execution package already defined in that repository. This type runs execution packages; it does not create them.The selection chainThe fields follow a chain: Gateway > Repository > Project > Execution package. Each field loads the next, and each has a refresh button. The editor describes them as follows.Execution connection. The gateway that runs the package. Timextender Cloud runs it without an on-premises gateway. Repository. The Timextender repository reachable through the selected gateway. Project. The project within the selected repository. Execution package. The execution package to run from the selected project.This type can run in TimeXt

Create a Fabric Capacity Pause/Resume packageA Fabric Capacity Pause/Resume package suspends or resumes a Microsoft Fabric capacity. Pausing stops you paying for a capacity that nothing is using.PrerequisitesAn Azure App Registration data provider in the workspace. This is the App Registration whose service principal the package acts as, and it decides which Azure resources you can choose. The principal able to enumerate resource groups in the subscription. This package finds its resource that way, so without this the resource list is empty and the package cannot be completed. The principal needs permission to change the resource, not only to read it. Listing a resource and acting on it are different rights.How it worksYou choose a data provider, then the capacity to act on, then what to do to it.When the resource list is empty, the editor names the scope it searched, for example No … were found in … this data provider can see. An empty list reflects the service principal's permissions

Create a TimeXtender Ingest packageA TimeXtender Ingest package runs an ingest task in TimeXtender Data Integration, the step that pulls data from a source system into the data estate. Use it when the loading is TimeXtender Data Integration's job but the timing and ordering of it belong in an orchestration flow alongside everything else.The package holds a reference to the TimeXtender Data Integration object, not a copy of it. Change what the task does in TimeXtender Data Integration and this package runs the new version, which is worth remembering before editing anything there that orchestration depends on.Three stages, three package types. Ingest is the first of the three TimeXtender Data Integration stages, and what it produces is what a Prepare package then transforms. All three are configured the same way: select a TimeXtender Data Integration connection, then select the task to run.PrerequisitesA TimeXtender Data Integration connection in the workspace. Selecting it loads the tas

Create a TimeXtender Deliver packageA TimeXtender Deliver package runs a deliver execution package in TimeXtender Data Integration, the step that publishes prepared data out to where it is consumed, such as a semantic model or a downstream database.The package holds a reference to the TimeXtender Data Integration object, not a copy of it. Change what the execution package does in TimeXtender Data Integration and this package runs the new version, which is worth remembering before editing anything there that orchestration depends on.Three stages, three package types. Deliver is the last of the three TimeXtender Data Integration stages, so it is normally the final one in a flow, and often the step immediately before a Power BI Refresh package. All three are configured the same way: select a TimeXtender Data Integration connection, then select the execution package to run.PrerequisitesA TimeXtender Data Integration connection in the workspace. Selecting it loads the execution packages ava

Create an Azure Virtual Machine Start/Stop packageAn Azure Virtual Machine Start/Stop package starts, restarts or shuts down a VM when it runs. Its usual job is to keep a machine running only while something needs it, for example a gateway VM that is required for the nightly load and idle for the other twenty hours.PrerequisitesAn Azure App Registration data provider in the workspace. This is the App Registration whose service principal the package acts as, and it decides which Azure resources you can choose. The principal able to enumerate resource groups in the subscription. This package finds its resource that way, so without this the resource list is empty and the package cannot be completed. The principal needs permission to change the resource, not only to read it. Listing a resource and acting on it are different rights.How it worksYou choose a data provider, then the virtual machine to act on, then what to do to it.When the resource list is empty, the editor names the scope it

Create a Fabric Capacity Scaling packageA Fabric Capacity Scaling package resizes a Microsoft Fabric capacity to another SKU when it runs. Use it to give the capacity more compute for a load window without pausing it, so reports keep working throughout.PrerequisitesAn Azure App Registration data provider in the workspace. This is the App Registration whose service principal the package acts as, and it decides which Azure resources you can choose. The principal able to enumerate resource groups in the subscription. This package finds its resource that way, so without this the resource list is empty and the package cannot be completed. The principal needs permission to change the resource, not only to read it. Listing a resource and scaling it are different rights.How it worksYou choose a data provider, then the capacity to act on, then what to do to it.When the resource list is empty, the editor names the scope it searched, for example No … were found in … this data provider can see. An

Create a TimeXtender Prepare packageA Timextender Prepare package runs a prepare execution package in TimeXtender Data Integration, the transformation step that shapes data already in the data estate into something reportable.The package holds a reference to the TimeXtender Data Integration object, not a copy of it. If you change what the execution package does inside TimeXtender Data Integration, this package runs the new version.Three stages, three package types. Prepare sits between Ingest and Deliver. It assumes the data is already in the estate, so it is usually ordered after an Ingest package and before a Deliver one. All three are configured the same way: choose a TimeXtender Data Integration connection, then choose the execution package to run.PrerequisitesA TimeXtender Data Integration connection in the workspace. Selecting the connection loads the execution packages available in that instance, so if the list is empty, check the connection first.Create the packageGo to Orchest

Create a Jet Analytics packageA Jet Analytics package runs an execution package from a Jet Analytics repository, so a Jet estate can be scheduled and monitored alongside the rest of your data platform.PrerequisitesA Jet Analytics repository reachable either from TimeXtender Cloud or through a gateway. An execution package already defined in that repository. This type runs execution packages; it does not create them.The selection chainThe fields follow a chain: Gateway > Repository > Project > Execution package. Each field loads the next, and each has a refresh button. The editor describes them as follows.Execution connection. The gateway that runs the package. Timextender Cloud runs it without an on-premises gateway. Repository. The Jet Analytics repository reachable through the selected gateway. Project. The project within the selected repository. Execution package. The execution package to run from the selected project.This type can run in TimeXtender Cloud. A gateway is nee

Create an Azure Function packageAn Azure Function package invokes an HTTP-triggered function. It is a good home for custom logic that does not belong in SQL or in a script on a gateway: calling a partner API, transforming a payload, or using a library that only exists in your function app.PrerequisitesAn Azure App Registration data provider in the workspace. An HTTP-triggered function. Timer-triggered and queue-triggered functions cannot be invoked this way and are not listed. The function's key, unless the function is anonymous.The function keyThe Function key is sent with the request. Leave it blank for anonymous functions. The stored key is never shown, so leave the field blank to keep the current key, or enter a new value to replace it.Two things follow from this. A blank field when you reopen a package does not mean the key was lost, it means the field does not display what is stored. And to rotate the key you enter the new one, with nothing to clear first.Keep the key in a global

Create an Azure PowerShell packageAn Azure PowerShell package runs a PowerShell script with the Az module inside an Azure context that the package sets up for you. Use it for the Azure housekeeping that has no purpose-built package type, such as tagging resources after a load, checking a storage account, or calling an Azure API that nothing else covers.Azure PowerShell or PowerShell? Searching the picker for PowerShell returns two types. Azure PowerShell, described on this page, authenticates to Azure for you from a data provider and hands the script an Azure context. PowerShell runs a plain script with no credential and no Azure involvement. If your script does not touch Azure, use the plain type: it needs no data provider.PrerequisitesAn Azure App Registration data provider in the workspace. The service principal able to enumerate resource groups in the subscription. Resource group is required and accepts a selection only, so without that permission the package cannot be completed. S

Create a Command Line packageA Command Line package runs an executable or a script on one of your own machines as a step in an orchestration flow. Use it for work that has to happen on your network and with your own tooling: running an SSIS package with dtexec, calling sqlcmd, driving a vendor's command line utility, or moving files between shares.Standard output and standard error are both captured in the execution log.This type always needs a gateway. Command Line packages run on a gateway rather than in TimeXtender Cloud. The editor pre-selects the first gateway registered for the tenant and requires one to be chosen. If you have no gateway, install one first. See Installing an execution connection.PrerequisitesPermission to create packages in the workspace. An ODQ Gateway installed and reachable. Knowing which identity the gateway service runs as, because that is the account your command runs under, not your own.Create the packageGo to Orchestration > Packages. Select Create, th

I run into this error while loadning csv-files from our s3 bucket.The issue is that the number of fields differs from time to time. We would like to ignore that and read these fields if they exists and otherwise not.Is there a way to do this or is this just an exception in CsvHelper-lib that isnt accessible for me to configure? The error:Executing table [csv].[VOF_UTF_Planeradebesok__aggregated]:failed with error:CsvHelper.MissingFieldException: Field with name 'Planerat besök - konfidentiellt' does not exist. You can ignore missing fields by setting MissingFieldFound to null.IReader state:   ColumnCount: 21   CurrentIndex: -1   HeaderRecord:["Användare - ID2","Användare - personnummer","Användare - profession","Avbruten/inställd","Brukare - ID2","Brukare - personnummer","Planerad resurs - namn","Planerat besök - dubbelbemanning","Planerat besök - ej utfört (anledning)","Planerat besök - sluttid","Planerat besök - starttid","Planerat besök - typ av brukare","Planerat besök - utfört","P

Hi,I have created an endpoint in my TimeXtender OData Data Source (provider version 1.4.1). I am currently using TimeXtender version 20.10.74.64.The endpoint supports incremental loading by applying a filter such as lastModifiedDateTime gt .... For the input variables, I use a Dynamic Value SQL query.We have three separate environments,Development, Test, and Production, hosted on different servers. The current environment is available through the TimeXtender variable vEnvironment.Is it possible to use a dynamic variable, such as vEnvironment, in the connection string to select the appropriate server?For example something like this?  Server = $(vEnvironment);Initial Catalog = ODX;Persist Security Info = ...  

Hi,I have two Execution Package chains ("Run Packages...") configured as follows:Chain 1:1a) Revenue 1b) Revenue Trigger 1c) Morning 1d) Morning TriggerChain 2:2a) Store 2b) Store TriggerThe requirement is that 2a) Store and 2b) Store Trigger must not run concurrently with 1c) Morning or 1d) Morning Trigger.I have configured this restriction in the Concurrent Packages section under Edit Execution Package. However, the restriction does not currently seem to be enforced as expected.Could this be because 1a) Revenue and 1b) Revenue Trigger are allowed to run concurrently with 2a) Store and 2b) Store Trigger?In other words, when Execution Packages are part of a chain, do the concurrency restrictions need to be configured for every package in the chain? Or should the restriction between 1c/1d and 2a/2b be sufficient to prevent those specific packages from running at the same time?

Hi all,We have regular ODX loads that periodically fail because of schema changes in Business Central (e.g. a new column added). The fix is straightforward: sync the metadata and rerun.I'm considering just adding the metadata sync step before every ODX load to avoid these failures altogether. Is there any downside to syncing every time? Could it cause unexpected behavior, longer run times (probably only a few minutes?), or anything else worth watching for?My instinct is that it's still better than having a load fail over a single new column, but wanted to check if this should be standard practice or if there's a reason this isn't already standard practice.Interested to hear your thoughts.

I'm using (legacy) TimeXtender version 20.10.82 with ODX.I messed up something in the .RSD file for a CData REST data source and subsequently fixed my mistake. But still, somehow, this has broken all tables in that data source. Executing the DSA tells me "Table not found in the data source" while the tables are clearly still there.I tried executing the synchonize task in the ODX and even deleted the .parquet files and fully loaded everything again. No luck. After "Synchonize objects" in my TimeXtender project all DSA tables lose their mappings to the ODX tables.TimeXtender probably tries to find the ODX tables but their id's have changed or whatever. Is there a way to fix this without remapping all my DSA tables?I'm 100% certain I've seen this behaviour before but on a smaller scale with less impact.

Hi,We're on TDI version 7387.1, using a TimeXtender REST Data Source in an Ingest instance to pull data from a paginated REST API (cursor-based pagination + a changed_after query parameter driven by a Dynamic Value SQL query).We want to run a post-execution SQL step (updating a small watermark/control table used by the Dynamic Value query) only after the transfer task has completed successfully - not before, and not if the run fails partway through.Our specific questions:1. Is there a supported way to attach a pre- or post-script (Script Action) directly to a REST data source's transfer task in an Ingest instance, similar to how Script Actions work on tables in a Data Warehouse/Staging instance?2. If this isn't natively supported on Ingest transfer tasks, what is the recommended pattern for reliably running a SQL step only after a specific ingestion task succeeds, when scheduling through Orchestration? We've seen the "dummy table with pre/post script" workaround mentioned in the commun