Skip to main content

    Filter by idea status

    Filter by product

    859 Ideas

    bas.hopstaken
    TimeXtender Xpert
    bas.hopstakenTimeXtender Xpert

    Support for Additional Connections in TDISUBMITTED

    In TimeXtender Classic (v20.10), it is possible to add additional connections. This is a very powerful feature that many of our customers are using.It is especially useful when you have many similar data sources (such as NAV/BC or Exact software). In our customer base, it is often the case that there is a separate database for each country, region, or office. Some of these customers frequently acquire new companies or open new offices. In such cases, these data sources can easily be added to the main data source connection. The transformations then also apply to these sources, all the way up to the semantic layers.In TDI, we do not have this option, even though it is a very powerful feature. For some of our customers, this is the only reason holding them back from migrating from Classic to TDI.A possible workaround in TDI could be to clone the data sources and adjust some settings. However, in that case, all tables still need to be mapped to the Prepare instance. You then have two options:Manually map all tables: You can use smart mapping, but it still requires a lot of work. Use mapping sets: This can be a very powerful feature, but in the current setup, you need to manually synchronize all mapping sets for all tables.An option to synchronize all mapping sets at once could also be a solution. Alternatively, and perhaps preferably, it would be great to have the ability to create additional connections in TDI as well.

    Ability to link multiple processes to a single process map.SUBMITTED

    Hi! Current state:When using orchestration , it's possible to link and synchronize a process with a process map. This is a great feature for monitoring and controlling a process!Problem:However, when building an overview of dependent processes (e.g. two or more processes that run within the same schedule), it would be very helpful to link multiple processes directly to a single process map. This would allow us to monitor and control them together from one central place.Workaround/ Solution finding:Our current workaround is to create an extra process that contains the individual processes as sub-steps, and then link that wrapper process to the process map (without scheduling it). While this technically works, it becomes messy over time and requires maintaining the same logic in multiple places. This increases the risk of errors and makes orchestration harder to manage.I did notice that within the process map builder, there is an option to add a process map to another process map (so nested maps). However, the task status indicators (success, warning, failed) do not reflect the actual status of the nested process map (see screenshots down below). Because of this, it's not reliable for monitoring or controlling multiple processes from a single map.Feature suggestion:Managing multiple processes from a single map would be easier if one of the following changes were implemented: Allow linking multiple processes directly to a single process map. Nested process maps reflect accurate status indicators for monitoring and control. Screenshots:Web interface (deployed):Nested map is always (even with failed tasks) a single green check. Redirects on click to the nested map.Editor view:From editor view it seems like it should show a list of indicators connected to the nested map. 

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Add option for manual field type input in Ingest MetadataSUBMITTED

    The current flow in Ingest Metadata Management is to ask the source what it contains, which will either get exact field types from DBMS-style sources or run a sample from many file- or API-based sources. In the latter variant, this is often a frustrating process: the actual type of a field may only be apparent in a record past the sampling threshold, or doing this might be slow.In the CData connectors, you would specify types in .rsd. This was annoying, but would at least result in what you needed. The current functionality leads to issues.Oftentimes we actually know what the type is beforehand and want to simply specify it instead of needing to load a lot of data. An example is an API that has a field that is actually a numeric(p,s) but mostly manifests as an integer. If there are more than one of these type of issues at the same time, it may be impossible to design a filter that allows for a one-shot metadata sync. Another example is a CSV file where Ingest detects nvarchar() fields where I know they are varchar(). As nvarchar() are a wider type, the resource consumption is much larger.I believe the flow is currently something like:source type → Ingest inferred type → (Override type) → Ingest storage type → (Implicit cast from Ingest to Prepare) → Prepare storageI would like to see a few extra options with respect to metadata:let me change types as delivered from source in the Metadata Manager. I am not sure there is value in setting the Ingest inferred type and then overriding after, so I suggest directly setting the Ingest storage type turn off type evaluation entirely. I might want to do this once and then keep up manually or just input the types myself, depending on the source. This means a metadata sync would only need to ask for tables/views/fields and should therefore be faster allow adding a filter only for metadata sync so that I can limit the amount of rows to evaulate for typing separately from transfer task filtering

    MartinMemelink
    Contributor
    MartinMemelinkContributor

    Change Power BI Semantic Model deployment checkSUBMITTED

    Given that is now possible to edit Semantic Models in the Power BI service, I would suggest to change the differential deployment check that TDI performs on these endpoints, so the data structure of the model is compared against Power BI instead of (or next to) the repository.Currently, some issues arise through the following steps:A Semantic Model is changed by some business user in the Power BI service (tables, relationships or measures are changed, added or deleted) Differential deploy in TDI will then compare the endpoint against the repository to determine if changes were made. There are no changes detected (because they were made in Power BI and not TDI) so we get the ‘No changes to deploy’ window. Going through with execution in TDI is subsequently ‘succesful’ even though entire tables can still be missing in Power BI, and we would have no way of knowing this is the case.The workaround currently is to always force deploy an endpoint as this re-creates the Semantic Model in Power BI conforming to the definition in TDI. And of course making sure that Power BI workspace members never edit the semantic models. But I still believe TDI should handle the possibility with more clarity.So the idea is to change the differential deployment check, so the semantic model definition is compared against the actual target model in Power BI alongside the repository.Secondly there should be a failure notification when executing a model with missing tables in Power BI.