Uploaded image for project: 'Pentaho Data Integration - Kettle'
  1. Pentaho Data Integration - Kettle
  2. PDI-18621

Using 'Open Referenced Object' removes Internal.Entry.Current.Directory from Sub Job in Spoon

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Severity: Urgent
    • Resolution: Fixed
    • Affects Version/s: 8.3.0.6 GA
    • Fix Version/s: 9.1.0 GA
    • Component/s: Job
    • Labels:
      None
    • Story Points:
      0
    • Notice:
      When an issue is open, the "Fix Version/s" field conveys a target, not necessarily a commitment. When an issue is closed, the "Fix Version/s" field conveys the version that the issue was fixed in.
    • Sprint Team:
      Mos Eisley
    • Steps to Reproduce:
      Hide

      Example Reproducible steps:

      Job 'S1' resides in Pentaho Repository in public/ETL/Sample/Folder1. It just calls Job 'S2' using hard coded path /public/ETL/Sample/Folder2/S2

      Job 'S2' resides in Pentaho Repository in public/ETL/Sample/Folder2. It just calls Job 'S3' using path variable ${Internal.Entry.Current.Directory}/S3

      Job 'S3' resides in Pentaho Repository in public/ETL/Sample/Folder2 (alongside S2). Job S3 does nothing (it just has 'Start' and 'Success')

      If Job S1 is run from Spoon (on a remote server confiuration, or on Pentaho Server, or Pentaho Local), it runs without issue.

      Steps:

      1) In Spoon, have only job S1 open on screen

      2) Right clicks the Job step (the one which calls S2), then selects 'Open Referenced Object> Job', then job S2 opens on screen.

      3) On inspecting the Job step within S2 (the one that calls S3), we see that the path to the job has CHANGED from:
      ${Internal.Entry.Current.Directory}/S3
      to:
      /public/ETL/Sample/Folder1/S3

      If the user then inadvertently hits Save, then the incorrect path is saved to the ktr stored in the repository

      Actual results:

      So, the issues are that:
      a) Job S2 is no longer set to point to ${Internal.Entry.Current.Directory}
      b) The path Spoon has replaced it with (without alerting the user) is wrong. It replaced it with the hard coded folder where job S1 resides, not the correct folder where jobs S2 and S3 reside (it should have been /public/ETL/Sample/Folder2/S3).

      So, moving on from this, if the user within job 'S2' right clicks the Job step (the one that calls S3) and selects 'Open Referenced Object> Job, then an error is returned to say:
      Unable to load job from path [/public/ETL/Sample/Folder1/S3.kjb]

      Expected results:

      When using 'Open Referenced Object> Job', the variable ${Internal.Entry.Current.Directory} should not be replaced with an incorrect hard coded path.

      Notes:

      • Jobs will be uploaded
      • If we instead use File> Open to open job S2, then the path remains correctly using ${Internal.Entry.Current.Directory.   It is only when using  'Open Referenced Object> Job' that this seems to happen.
      Show
      Example Reproducible steps: Job 'S1' resides in Pentaho Repository in public/ETL/Sample/Folder1. It just calls Job 'S2' using hard coded path /public/ETL/Sample/Folder2/S2 Job 'S2' resides in Pentaho Repository in public/ETL/Sample/Folder2. It just calls Job 'S3' using path variable ${Internal.Entry.Current.Directory}/S3 Job 'S3' resides in Pentaho Repository in public/ETL/Sample/Folder2 (alongside S2). Job S3 does nothing (it just has 'Start' and 'Success') If Job S1 is run from Spoon (on a remote server confiuration, or on Pentaho Server, or Pentaho Local), it runs without issue. Steps: 1) In Spoon, have only job S1 open on screen 2) Right clicks the Job step (the one which calls S2), then selects 'Open Referenced Object> Job', then job S2 opens on screen. 3) On inspecting the Job step within S2 (the one that calls S3), we see that the path to the job has CHANGED from: ${Internal.Entry.Current.Directory}/S3 to: /public/ETL/Sample/Folder1/S3 If the user then inadvertently hits Save, then the incorrect path is saved to the ktr stored in the repository Actual results: So, the issues are that: a) Job S2 is no longer set to point to ${Internal.Entry.Current.Directory} b) The path Spoon has replaced it with (without alerting the user) is wrong. It replaced it with the hard coded folder where job S1 resides, not the correct folder where jobs S2 and S3 reside (it should have been /public/ETL/Sample/Folder2/S3). So, moving on from this, if the user within job 'S2' right clicks the Job step (the one that calls S3) and selects 'Open Referenced Object> Job, then an error is returned to say: Unable to load job from path [/public/ETL/Sample/Folder1/S3.kjb] Expected results: When using 'Open Referenced Object> Job', the variable ${Internal.Entry.Current.Directory} should not be replaced with an incorrect hard coded path. Notes: Jobs will be uploaded If we instead use File> Open to open job S2, then the path remains correctly using ${Internal.Entry.Current.Directory.   It is only when using  'Open Referenced Object> Job' that this seems to happen.

      Description

      Whilst connected to Pentaho Repository in Spoon, If we have a parent job open in Spoon and we right click a Job step & choose 'Open Referenced Object> Job' then the sub job does open on screen. However, if that sub job contained another Job step which had a path using ${Internal.Entry.Current.Directory, then the ${Internal.Entry.Current.Directory variable is replaced with the hard coded current folder of the parent job.

        Attachments

        1. S1.kjb
          19 kB
        2. s2.kjb
          19 kB
        3. s3.kjb
          18 kB

          Issue Links

            Activity

              People

              Assignee:
              vshalkova Viktoryia Shalkova
              Reporter:
              sfrench Stuart French
              Votes:
              2 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: