3 Replies Latest reply on May 24, 2018 8:50 AM by Ramesh Reddy

    Utility of source model for a rest call

    Mathieu Rampant Newbie

      Hi,

      I recently created a VDB and when using Rest with query parameters, I noticed a source model still needs to be referenced but is not really used?

      Here is the transformation that was generated:

      BEGIN
        DECLARE STRING VARIABLES.qp = QUERYSTRING('http://toto.com', view.view.created_date AS created_date);
        SELECT A.cost AS cost, A.id AS id, PARSEDATE(A.created_date, 'yyyy-MM-dd') AS created_date FROM (EXEC source.invokeHttp(action => 'GET', endpoint => VARIABLES.qp, 
      stream => 'TRUE', XMLTABLE('/response/response' PASSING JSONTOXML('response', f.result) COLUMNS cost float PATH 'cost/text()', id string PATH 'id/text()', 
      created_date string PATH 'created_date/text()') AS A;
      END
      
      

       

      Since the URL is contained in the variables, what is the point of have a "source" to use invokehttp on?

      My source is configured using a DataSource with a certain URL, and if I set a different URL I notice the one in the transformation is used.

      So, my questions are the following:

      • why is the source required to make a standard http call?
      • why does the source contain a endpoint that isn't used?
      • why is a DataSource also required? In this case the url contained in the datasource isn't used at all
      • Could I use a generic source for all my Rest Calls?

       

      I feel like I have to set a data source, with a URL, then a Source model, with the URL once again, and finally a View model with the URL again! All of that to realize the only one being used in this case is the one in the View Model Transformation.

       

      If I don't use QUERYSTRING, then the URL from my Data Source is used instead.

       

      I am a little confused, if you'd be so kind as to give me a little background info and explanation, I would really appreciate it.

       

      Thanks!

        • 1. Re: Utility of source model for a rest call
          Steven Hawkins Master

          > Since the URL is contained in the variables, what is the point of have a "source" to use invokehttp on?

           

          As you point out later on the associated source and datasource can contain a default url.  There is a lot of other configuration that can associated with the datasource as well - you have some builtin Teiid logic around security and the full power of CXF if needed.

           

          > why does the source contain a endpoint that isn't used?

           

          It's used as a default, and it is not a required property on the datasource.  If you don't have a valid default, relative or otherwise, just leave it off of the datasource configuration.  It does look like the Teiid metadata in the ra.xml indicates that it's required, which would be reported by Teiid Designer, but that should be corrected.

           

          >  why is a DataSource also required? In this case the url contained in the datasource isn't used at all

           

          A source model typically represents a datasource.  A datasource is required as it provides a JCA compatible way to configure connectivity to external systems.

           

          > Could I use a generic source for all my Rest Calls?

           

          Yes.  If you just want 1 webservices datasource on the server and just 1 source representing it per vdb, that's perfectly fine.  You can do whatever fits your usage model.

           

          > I feel like I have to set a data source, with a URL, then a Source model, with the URL once again, and finally a View model with the URL again! All of that to realize the only one being used in this case is the one in the View Model Transformation.

           

          Yes you need a datasource - but the url there is optional.  You have a source model that represents the datasource - it should define the invoke procedure, but it would not have a url as it's just a procedure definition.  In your virtual model, or user sql, you are calling the source procedure in whatever way is needed.

           

           

           

           

           

           

           

           

          • 2. Re: Utility of source model for a rest call
            Mathieu Rampant Newbie

            Thank you, that is very useful.

            I realize that Teiid Designer is somewhat stricter than Teiid really is behind the scene. When I try to select the same source model in Teiid Designer it tells me it's not compatible, even though it can be. I just have to do it manually. I tried and it does indeed work.

            Also I have noticed Teiid query parameters for Rest data source don't accept anything else than letter or numbers (my parameter was created_date) so I had to create on without underscore, and then edit it through the procedure definition and there I was able to use the underscore.

             

            I often find myself editing XML directly because of the lack of flexibility of Teiid Designer

            I am curious, is there an alternative to Teiid Designer? What do you guys use to test and work on the latest versions of Teiid?

            I'd love to upgrade, but I am stuck on 9.0.6 since it's compatible with Teiid Designer

             

            Thanks again for the info!

            • 3. Re: Utility of source model for a rest call
              Ramesh Reddy Master

              There no direct UI alternatives to Teiid Designer. We use Dynamic VDB in XML/DDL or pure DDL form for any testing, which gives as you mention an easier editing of the VDB. Note that you can always start developing on Designer and at the end export it into the XML/DDL format and then start using that as your VDB. There is an import option too. Also, Teiid Designer may directly support only older versions of Teiid, but the VDB generated can be used on latest editions of Teiid without any changes as metadata language inside the VDB has not been changed or evolves only in a backward compatible way for the most part.

               

              We are also developing an OpenShift cloud-native tooling Beetle, but not as a replacement.