Skip to main content

    Filter by idea status

    Filter by product

    863 Ideas

    andrew.gebhard
    TimeXtender Xpert
    andrew.gebhardTimeXtender Xpert

    Manage Job QueueSUBMITTED

    Hi team, An issue that I am running into relatively often is that a job fails to fail or complete, staying in the ‘running’ state indefinitely. Sometimes cloud services can experience transient issues, which may cause these anomalies. More importantly, however, there is no way to clear the queue, stop existing jobs, or force a job to restart when it's already running. Furthermore, there is no timeout on jobs, so they can continue to run forever.Example: this job has been in the running state for about 30 hours. It runs a number of Ingest Transfer and Cleanup tasks:Job MonitorIn the ODX Execution Queue I can see that there are no ODX tasks waiting or running, so I cannot cancel anything from there: Ingest Instance Execution QueueStarting the job manually or via eXmon does not work, I get the message failed to run message from eXmon: “The TimeXtender job 'ODX - OneLake and FTP - Transfer + Cleanup' is already running”. If this was a prepare or deliver job, it would now be blocking the other prepare or delivery jobs from running. -- The only way to reset the jobs is by stopping the ODX Service and restarting it. This causes all ODX tasks (also outbound) to fail instantly, which is far from ideal in an environment where data is constantly being loaded, and lengthy reloads may be running outside of work hours. It's also difficult to explain to a client that they may need to do this periodically to keep their environment running. We should have more control over the how jobs run, fail, and cancel. Jobs waiting or running in the queue should be able to be removed without restarting a service and a large unplanned impact to the platform. Kind regards,Andrew

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Improve synchronizing Prepare Instance with Ingest InstanceSUBMITTED

    In the 6xxx release when you synchronize your Prepare instance with an Ingest instance there are two things that may happen:TimeXtender automatically handles changes, no input is required. TimeXtender cannot automatically deal with the changes and user input is required to tell TimeXtender how mappings should be set up.In both cases, there are significant improvements to be made (or deficiencies handled). I will list my issues and suggestions for each in the following sections:Changes can be handled automaticallyIt is usually great that TimeXtender handles things for you, but there is currently no way of seeing the changes that were applied. In the 20.10.x BU setup, a source synch would show you what changes were applied. In my opinion what should be available is the following:a synchronize which can be auto-resolved should show the proposed (additions, removals, mutations) changes. It only applies them if the user agrees it should be possible to review the current mapping state in its totality the interface showing all mappings should be sortableChanges cannot be handled automaticallyWhen TimeXtender cannot handle changes, it shows a dialogue with all mappings (one line per table, followed by all field mappings). You need to scroll through a potentially huge list of mappings to find any that are problematic. This dialogue will not accept empty (None) mappings and give you a warning. What we need here is the following:the interface showing all mappings should be sortable (to quickly sort on tables with errors) it should be possible to collapse and expand tables (start with everything collapsed) so that fields can be hidden for a shorter list it should be possible to select None as a mapping. If a field is removed from source, there is no reason why None is not a valid mapping to DWH. It is fine to mark the field visually, but if I want a field without a mapping that is not always an error it should be possible to filter the interface so I can focus on the problems only instead of needing to scroll through thousands of mappings with pgdn to try and find one problematic mapping it should be possible to review the current mapping state in its totalityI am not sure how mapping sets are currently visualised (if they are at all), but those rules should be reachable from the general mapping interface.