Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. To start the preview for an application: 
    Request Method and Endpoint 

    Code Block
    POST /v3/namespaces/{namespace-id}/apps/{app-id}/preview
    where namespace-id is the name of the namespace
          app-id is the name of the application for which preview is to be seenpreviewed
    
    Note that user will have to provide the app-id for the preview request.
     
    Response will contain the CDAP generated unique preview_id which can be used further to get the preview data per stage.

    Request body will contain the application configuration along with following additional configs for the preview.

    Code Block1. Connection configuration in the application JSON will be updated to specify the inputData. Consider following sample DAG.

    a.  Connection configuration in the application JSON can be updated to specify the input mock data for the destination stage of the connection.

    Code Block
    Consider pipeline represented by following connections.
    
    "connections":[  
             {  
                "from":"FTP",
                "to":"CSVParser"
             },
             {  
                "from":"CSVParser",
                "to":"Table"
             }
          	]
    
    Now if user wants to provide the input data to the CSVParser instead of reading it from FTP source the inputData can be provided as:
    "connections":[  
             {  
                "from":"FTP",
                "to":"CSVParser",
    			"inputData"  : [
                                     {"offset": 1, "body": "100,bob"}, 
                                     {"offset": 2, "body": "200,rob"}, 
                                     {"offset": 3, "body": "300,tom"}
                                  ]
             },
             {  
                "from":"CSVParser",
                "to":"Table"
             }
          	]
      
    The above configuration indicates that connection from FTP to CSVParser need to be updated to read the inputData instead of reading it from FTP.  
    2. In case there are multiple sources in the pipeline and user wants to provide mock data for all of them, then every connection emitted from the source will need to be updated with the inputData.
    3. If user wants to read the actual data from the S3 Source as a part of preview, numOfRecords can be specified for each connection emitted from the Source as
     
     "connections": [Source directly.


    b. In case there are multiple sources in the pipeline or multiple stages reading from the same source and user wants to provide the mock data for all of them, then every connection emitted from the source need to have the inputData associated with it.

    Code Block
    Consider the following pipeline:
     "connections": [
            {
                "from": "S3 Source",
                "to": "Log Parser"
            },
            {
                "from": "S3Log SourceParser",
                "to": "LogGroup Parser",
    			"numOfRecords": 10By Aggregator"
            },
            {
                "from": "LogGroup By ParserAggregator",
                "to": "GroupAggregated By AggregatorResult"
            },
            {
                "from": "GroupS3 By AggregatorSource",
                "to": "AggregatedRaw ResultLogs"
            },
        ]
    
    Now if {user want to preview the pipeline but do now want to read the data "from": the "S3 Source", connections can be updated with the inputData information as 
     "connections": [
            {
                "tofrom": "RawS3 LogsSource",
                "numOfRecordsto": 10"Log Parser",
    			"inputData": {[
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"
    	
    					 ]	
    }
            },
        ]  In the above{
    example configuration, 10 records will be read from the S3 Source in order to pass them to the "from": "Log Parser",
    however  since the inputData is specified for the connection S3 Source "to Raw Logs, inputData will be passed to Raw Logs without reading from the S3 Source.
     
    4. If user want to ignore writing to the sink, following are few options for having it as a configuration:
     
    "preview": {
     ": "Group By Aggregator"
            },
            {
                "from": "Group By Aggregator",
                 "numRecordsto" : "10Aggregated Result",
            },
          "startStage" : "stage_1", {
                "from": "S3 Source",
    "endStage"   : "stage_3",        "to": "Raw       Logs",
    			"inputData"  : [
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 -                      {"name": "rob", "address": "san jose"}, bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"	
    						 ]
            }
        ]


    c. If user wants to use actual source for the preview, the number of records read from the source can be limited by the numOfRecords property. 

    Code Block
     "connections": [
            {
                {"namefrom": "bobS3 Source",
      "address          "to": "santaLog claraParser"}, 
    			"numOfRecords": 10
            },
            {
                 {"namefrom": "tomLog Parser",
    "address": "palo alto"}          "to": "Group By Aggregator"
            },
            ]{
    			   "programType": "WORKFLOW", // programType and programName can be optional for now. However in future if we want to preview non-hydrator application, then programType and programName can be provided to let preview system know which program to be previewed
    			   "programName": "DataPipelineWorkflow"		"from": "Group By Aggregator",
                "to": "Aggregated Result"
            },
            {
                }
     
    Description"from": 1. numRecords: Number of records to preview
    2. startStage: Pipeline stage from which preview need to be started.
    3. endStage: Pipeline stage till which the preview need to be run.
    4. inputData: Data which need to be run through preview process.
     
    Validations to be performed:
    1. startStage and endStage are connected together.
    2. Schema of the inputData should match with the input schema for stage_1.
    3. If SOURCE plugin is specified as startStage, preview will ignore the inputData and read the records directly from the source as specified by the numRecords.
    4. If startStage is other than the Source plugin then inputData is required. Preview will process the inputData ignoring numRecords.

    Consider the pipeline which has FTP source, CSV parser labeled as MyCSVParser and Table sink labeled as MyTable. The configuration with preview data will look like following:

    Code Block
    {
    	"artifact":{  
          "name":"cdap-data-pipeline",
          "version":"3.5.0-SNAPSHOT",
          "scope":"SYSTEM"
        },
        "name":"MyPipeline",	
    	"config":{
    		"connections":[  
             {  "S3 Source",
                "to": "Raw Logs",
                "numOfRecords": 10,
    			"inputData": [
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"	
    
    						 ]
            }
        ]
     
    In the above example configuration, 10 records will be read from the S3 Source in order to pass them to the Log Parser, however since the inputData is specified for the connection S3 Source to Raw Logs, inputData will be passed to Raw Logs without reading from the S3 Source.

    d. If user do not want to write to the sink, following are few possible approaches:

    Code Block
    Approach a) Specify list of sinks to ignore using ignoreSinks property.
    
    "preview" : {
    				"ignoreSinks" : ["Raw Logs"]  
    			}
    
    Approach b) For each connection to the Sink we can add the ignoreConnection property and set it to true as
     "connections": [
            {
                "from": "FTPS3 Source",
                "to":"CSVParser"
     "Log Parser",
    			"numOfRecords": 10
            },
    
            {  
                "from": "CSVParserLog Parser",
                "to": "TableGroup By Aggregator"
            },
    }       	],
    		"stages":[ {
                {  "from": "Group By Aggregator",
                "nameto": "FTPAggregated Result",
            },
       "plugin":{     {
                "namefrom": "FTPS3 Source",
    
                  "typeto": "batchsourceRaw Logs",
    			"numOfRecords": 10,
    			"ignoreConnection": "true"
            }
      "label":"FTP",  ]
    
    In the example configuration above, preview will write to the Aggregated  "artifact":{  
           Results, however would not write to the Raw Logs.


    e. Preview single stage:

    Code Block
    Consider pipeline connections:
    "connections":[  
            "name":"core-plugins",
        {  
                "versionfrom":"1.4.0-SNAPSHOTFTP",
      
                   "scopeto":"SYSTEMCSVParser"
        
              },
             {  
       "properties":{         "from":"S3",
                "referenceNameto":"myfileCSVParser",
             },
             "path":"/tmp/myfile"{  
                 }
                }"from":"CSVParser",
                "outputSchemato":"{\"fields\":[{\"name\":\"offset\",\"type\":\"long\"},{\"name\":\"body\",\"type\":\"string\"}]}"Table"
             },
          	]
     
    CSVParser {in the above pipeline has two input connections, one from FTP and another from S3. 
    In  "name":"MyCSVParser",
                "plugin":{order to preview the single stage CSVParser following configurations can be specified -
     
    "connections":[  
             {  
       "name":"CSVParser",
                   "typefrom":"transformFTP",
      
                "labelto":"CSVParser",
    			"inputData"  : [
                "artifact":{                     {"nameoffset":"transform-plugins" 1, "body": "100,bob"}, 
                   "version":"1.4.0-SNAPSHOT",                  {"offset": 2, "scopebody": "SYSTEM"200,rob"}, 
                     },                "properties":{{"offset": 3, "body": "300,tom"}
                                   "format":"DEFAULT",]
             },
             "schema":"{\"type\":\"record\",\"name\":\"etlSchemaBody\",\"fields\":[{\"name\":\"id\",\"type\":\"int\"},{\"name\":\"name\",\"type\":\"string\"}]}",
         {  
                "fieldfrom":"bodyS3",
                   }"to":"CSVParser",
    			"inputData"  : [
                        },             {"outputSchemaoffset":"{\"type\":\"record\",\"name\":\"etlSchemaBody\",\"fields\":[{\"name\":\"id\",\"type\":\"int\"},{\"name\":\"name\",\"type\":\"string\"}]}" 1, "body": "500,milo"}, 
                                     {"offset": 2, "body": "600,whitney"}, 
            },          {               {"nameoffset":"MyTable", 3, "body": "700,yosemite"}
                "plugin":{                  "name":"Table",]
             },
         "type":"batchsink",    {  
                "labelfrom":"TableCSVParser",
                   "artifactto":{"Table"
             }
          	]
    "preview": {
     	"nameendStages": ["core-pluginsCSVParser",]
    }
     
    Note that in 3.5, only one stage can be provided as a endStages and when  "version":"1.4.0-SNAPSHOT",
                      "scope":"SYSTEM"
    endStages is specified, inputData must be provided for all the incoming connections to that stage.


    f. NOT in 3.5   In order to execute the section of the pipeline, endStages can be provided.

    Code Block
    Consider the following pipeline:
     "connections": [
            {
         },       "from": "S3 Source",
                "propertiesto":{ "Log Parser"
            },
            {
                "schemafrom":"{\"type\":\"record\",\"name\":\"etlSchemaBody\",\"fields\":[{\"name\":\"id\",\"type\":\"int\"},{\"name\":\"name\",\"type\":\"string\"}]}", "Log Parser",
                "to": "Group By Aggregator"
            "name":"mytable",},
            {
                "schema.row.field":"id""from": "Group By Aggregator",
                "to": "Aggregated Result"
        }    },
            },{
                "outputSchemafrom":"{\"type\":\"record\",\"name\":\"etlSchemaBody\",\"fields\":[{\"name\":\"id\",\"type\":\"int\"},{\"name\":\"name\",\"type\":\"string\"}]}",
                "inputSchema":[  
                   {  
                      "name":"id",
                      "type":"int",
                      "nullable":false
                   },
                   {  
                      "name":"name",
                      "type":"string",
                      "nullable":false
                   }
                ]
             }
          ],
    	   "preview": {
                   "numRecords" : "10",
                   "startStage" : "MyCSVParser",
                   "endStage"   : "MyTable",
                   "inputData"  : [
                                     {"offset": 1, "body": "100,bob"}, 
                                     {"offset": 2, "body": "200,rob"}, 
                                     {"offset": 3, "body": "300,tom"}
                                  ]
    		}
    
    	}
    }

    The above preview configuration will read the inputData from preview section and write the data to MyTable. If user does not want to write the data to the sink but only want to preview the MyCSVParser stage the preview configurations will look like below:

    Code Block
    "preview": {
                   "numRecords" : "10",
                   "startStage" : "MyCSVParser",
                   "endStage"   : "MyCSVParser", // In order to execute single stage start stage is same as end stage
                   "inputData"  : [
                                     {"offset": 1, "body": "100,bob"}, 
                                     {"offset": 2, "body": "200,rob"}, 
                                     {"offset": 3, "body": "300,tom"}
                                  ]
    		}

     

    a.  Connection configuration in the application JSON can be updated to specify the input mock data for the destination stage of the connection.

    Code Block
    Consider following sample DAG.
    
    
    "connections":[  
             {  
                "from":"FTP",
                "to":"CSVParser"
             },
             {  
                "from":"CSVParser",
                "to":"Table"
             }
          	]
    
    Now if user wants to provide the input data to the CSVParser instead of reading it from FTP source the inputData can be provided as:
    "connections":[  
             {  
                "from":"FTP",
                "to":"CSVParser",
    			"inputData"  : [
                                     {"offset": 1, "body": "100,bob"}, 
                                     {"offset": 2, "body": "200,rob"}, 
                                     {"offset": 3, "body": "300,tom"}
                                  ]
             },
             {  
                "from":"CSVParser",
                "to":"Table"
             }
          	]
     
    The above configuration indicates that connection from FTP to CSVParser need to be updated to read the inputData instead of reading it from FTP Source directly.
    b. In case there are multiple sources in the pipeline or multiple stages reading from the same source and user wants to provide the mock data for all of them, then every connection emitted from the source need to have the inputData associated with it.
    Code Block
    For example consider the following pipeline DAG
     "connections": [
            {
                "from": "S3 Source",
                "to": "Log Parser"
            },
            {
                "from": "Log Parser",
                "to": "Group By Aggregator"
            },
            {
                "from": "Group By Aggregator",
                "to": "Aggregated Result"
            },
            {
                "from": "S3 Source",
                "to": "Raw Logs"
            }
        ]
    
    Now if user want to preview the pipeline but do now want to read the data from the S3 Source, connections can be updated with the inputData information as 
     "connections": [
            {
                "from": "S3 Source",
                "to": "Log Parser",
    			"inputData": {
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    
    							"127.0.0.1 - bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"
    						 }	
    
            },
            {
                "from": "Log Parser",
                "to": "Group By Aggregator"
            },
            {
                "from": "Group By Aggregator",
                "to": "Aggregated Result"
            },
            {
                "from": "S3 Source",
                "to": "Raw Logs",
    			"inputData": {
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"	
    
    						 }
            }
        ]
    c. If user wants to use actual source for the preview, the number of records read from the source can be limited by the numOfRecords property. 
    Code Block
     "connections": [
            {
                "from": "S3 Source",
                "to": "Log Parser",
    			"numOfRecords": 10
            },
            {
                "from": "Log Parser",
                "to": "Group By Aggregator"
            },
            {
                "from": "Group By Aggregator",
                "to": "Aggregated Result"
            },
            {
                "from": "S3 Source",
                "to": "Raw Logs",
                "numOfRecords": 10,
    			"inputData": {
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"	
    
    						 }
            }
        ]
     
    In the above example configuration, 10 records will be read from the S3 Source in order to pass them to the Log Parser, however since the inputData is specified for the connection S3 Source to Raw Logs, inputData will be passed to Raw Logs without reading from the S3 Source.

    d. If user do not want to write to the sink, following are few configuration options are available:

    Code Block
    Option a) Specify list of sinks to ignore writing to using ignoreSinks property.
    
    "preview" : {
    				"ignoreSinks" : ["Raw Logs", "Aggregated Results"]  
    			}
    
    Option b) For each connection to the Sink we can add the ignoreConnection property and set it to true as
     "connections": [
            {
                "from": "S3 Source",
                "to": "Log Parser",
    			"numOfRecords": 10 "S3 Source",
                "to": "Raw Logs"
            }
        ]
     
     
    (S3 Source) --------->(Log Parser)--------->(Group By Aggregator)--------->(Aggregated Result)
                |
    			|
    			--------->(Raw Data)	
     
    Now if user wants to preview (Log Parser)--------->(Group By Aggregator) section of the pipeline, endStages can be provided as Group By Aggregator using following configurations:
     
    "connections": [
            {
                "from": "S3 Source",
                "to": "Log Parser",
    			"inputData": [
    							"127.0.0.1 - frank [10/Oct/2000:13:55:36 -0800] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - bob [10/Oct/2000:14:55:36 -0710] GET /apache_pb.gif HTTP/1.0 200 2326",
    							"127.0.0.1 - tom [10/Oct/2000:23:55:36 -0920] GET /apache_pb.gif HTTP/1.0 200 2326"
    						 ]	
            },
            {
                "from": "Log Parser",
                "to": "Group By Aggregator"
            },
            {
                "from": "Group By Aggregator",
                "to": "Aggregated Result",
    			"ignoreConnection":
    "true"         },
            {
                "from": "S3 Source",
                "to": "Raw Logs",
    			"numOfRecords": 10
             }
        ]
    
    "preview": In the example configuration above, preview will write to the Raw Logs, however writing to the sink Aggregated Result is ignored.
    e. 
    f.
    {
    	"endStages": ["Group By Aggregator"],
        "ignoreSinks": ["Raw Logs"]    
    }
     
      
  2.  

  3. Once the preview is started, the unique preview id will be generated for it. Preview id could be of the form: namespace_id.app_id.preview. The runtime information (<Preview_id, STATUS) for the preview will be generated and will be stored (in-memory or disk). While preview is running if user again sends the preview request for the same application and the STATUS is RUNNING, user will get 403 status code with "Preview already running for application." error message. This enforces only one preview is running at any instance of time for a given application in a given namespace.

  4. If the startStage in the preview configurations is not SOURCE plugin, then the preview system will generate the MOCK source in the pipeline which will read the JSON records specified in the inputData field and convert them into the StructureRecord.

  5. Once the preview execution is complete, its runtime information will be updated with the status of the preview (COMPLETED or FAILED).

  6. To get the status of the preview
    Request Method and Endpoint

    Code Block
    GET /v3/namespaces/{namespace-id}/apps/{app-id}/preview/status
    where namespace-id is the name of the namespace
          app-id is the name of the application for which preview data is to be requested

    Response body will contain JSON encoded preview status and optional message if the preview failed.

    Code Block
    1. If preview is RUNNING
    {
    	"status": "RUNNING" 
    }
    
    2. If preview is COMPLETED
    {
    	"status": "COMPLETED" 
    }
    
    3. If preview FAILED
    {
    	"status": "FAILED"
        "errorMessage": "Preview failure root cause message." 
    }
  7. To get the preview data for stage:
    Request Method and Endpoint

    Code Block
    GET /v3/namespaces/{namespace-id}/apps/{app-id}/preview/stages/{stage-name}
    where namespace-id is the name of the namespace
          app-id is the name of the application for which preview data is to be requested
          stage-name is the unique name used to identify the stage

    Response body will contain JSON encoded input data and output data for the stage as well as input and output schema.

    Code Block
    {
    	"inputData": [
                     	{"first_name": "rob", "zipcode": 95131},
                        {"first_name": "bob", "zipcode": 95054},
                        {"first_name": "tom", "zipcode": 94306}
                     ],
    	"outputData":[
    					{"name": "rob", "zipcode": 95131, "age": 21},
                        {"name": "bob", "zipcode": 95054, "age": 22},
                        {"name": "tom", "zipcode": 94306, "age": 23}
    				 ],
    	"inputSchema": {
    						"type":"record",
    						"name":"etlSchemaBody",
    						"fields":[
    									{"name":"first_name", "type":"string"},
    									{"name":"zipcode", "type":"int"}
    								 ]
    					},
    	"outputSchema": {
    						"type":"record",
    						"name":"etlSchemaBody",
    						"fields":[
    									{"name":"name", "type":"string"},
    									{"name":"zipcode", "type":"int"},
    									{"name":"age", "type":"int"}
    								 ]
    					}  
    }
  8. To get the logs/metrics for the preview:
    Request Method and Endpoint

    Code Block
    GET /v3/namespaces/{namespace-id}/apps/{app-id}/preview/logs
    GET /v3/namespaces/{namespace-id}/apps/{app-id}/preview/metric
    where namespace-id is the name of the namespace
          app-id is the name of the application for which preview data is to be requested

    Response would be similar to the regular app.

...