We recommend using our CSV library, which provides a convenience wrapper
around the build-in CSV functions. However, the functions work well on their own too.
If you are using bare PHP functions, the following code illustrates their use:
Note that we open both the input and output files simultaneously; as soon as a row is processed,
it is immediately written to the destination file. This approach keeps only a single row of data in the memory and is
generally very efficient. It is recommended to implement the processing in this way because data files
coming from KBC can be quite large.
The same can be achieved via the CSV library. Install the
package with composer require keboola/csv. The following
piece of code uses it and reads the configuration file.
read and parse the configuration file and parameters:
getConfig method or getConfig()->getParameters() methods.
list input files and tables: getConfig()->getInputFiles(), getConfig()->getInputTables() methods.
work with manifests containing table and file metadata: getManifestManager()->getTableManifest(), getManifestManager()->writeTableManifest(), getManifestManager()->getFileManifest(), getManifestManager()->writeFileManifest() methods.
list expected outputs: getConfig()->getExpectedOutputFiles() or getConfig()->getExpectedOutputTables() methods.
You can go through the generated docs of all available methods and classes.
The package can be installed by Composer:
composer require keboola/php-component
The package can be used standalone (good for existing code), or you can inherit your own component from it (good for new components).
When inheriting from the package, see the GitHub repository for examples, or
our component template.
Using the package as a standalone class does not require anything else than creating its instance:
In the tutorial and the above examples, we show
applications which have names of their input/output tables hard-coded.
The following example shows how to read an input and output mapping specified by the end user,
which is accessible in the configuration file. It demonstrates
how to read and write tables and table manifests. File manifests are handled the same way. For a full authoritative list
of items returned in table list and manifest contents, see the specification.
Note that the destination label in the script refers to the destination from the
The input mapper takes source tables from the user’s storage and produces destination tables that become
the input of your component. The output tables of your component are consumed by the output mapper
whose destination are the resulting tables in Storage.
The following piece of code reads an arbitrary number of tables and adds an auto-generated primary key
to them. The name of the added column is configured in parameters (primaryKeyName). Also, the
step of the generator is configured in parameters (primaryKeyStep). The end of the code writes
a table manifest file which stores the configuration of
the primary key and optional table metadata.
For simple applications, printing with echo or print is enough. To print to STDERR, you have to use
e.g., fwrite(STDERR, "Hello, world!" . PHP_EOL);. The best option is to use the Monolog package.
The following is a useful initialization:
This means that a log with the NOTICE level and above
will go to STDERR, and the INFO level will go to STDOUT. The formatter removes unnecessary fields like timestamp and context.
In this case, we consider everything derived from UserException to be an error which should be shown to the end user.
You have to create that exception class in your component. Every other error will lead to a generic message; only
the developer will see the details, and the code will follow the general error handling rules.
Here we use the Throwable ancestor, which also catches PHP errors. You can, of
course, modify this logic to your liking.