TABLE OF CONTENTS

• Introduction
• Example Library Block
• Custom Sections
• Removing blocks from the Blocks Library
• Converting a Library Block to a standard Custom Block
• Block Library location on disk
• Private company-wide Custom Block Repository

Introduction

The Blocks Library is a user controlled collection of Custom Blocks which are maintained from a single folder on disk. Library blocks can be placed just like ordinary blocks by dragging them from the block picker onto a workflow. Once they are part of a workflow, any change made to its source files on disk is immediately reflected to all library blocks in all workflows.

By default the blocks library is located next to the sharing folder in a directory called "blocks-library" within the "omniscope-server" folder.

	The library is pre-populated with folders which correspond to the main sections in the block picker

Any custom block placed into a subdirectory of these folders will immediately be available to any workflow through the block picker. When added to a workflow, they cannot be edited from within the block dialog. They are instead maintained from the blocks library on disk. Any change there is immediately propagated to any workflow in which the library block is used.

Example Library Block

As an example, let's add a custom MongoDB connector to the Inputs section of the block picker.

First we create a standard Custom Block by dragging a Python (or "R") custom script block onto the workflow.

Afterwards we edit the options and script to create the functionality that allows the block to connect to MongoDB data bases. For an overview of how to create Custom Blocks, please see the Getting Started Custom Block Tutorial. 

Now, the Custom Block can be exported through the menu in the block dialog.

Exporting the block produces a zip file. Extracting the zip file reveals two files, a manifest.json and a script.py. 

Now we simply create a subdirectory in the Inputs folder and copy the manifest.json and script.py (or script.R for R-based blocks) into it.

The new bock is immediately available in the block picker:

Adding it to a workflow let's you configure its options, but not its script:

Modifying the options or script on disk will immediately change the block in the workflow.

For example, changing the property introductoryText in the manifest.json to start with MongoDatabase instead of MongoDB...

... will immediately change the text above the options to the modified one:

Custom Sections

You are not required to just use the pre-populated top level folders within the block library. New folders create new sections in the block picker.

For example, adding a folder called Databases and populating it with the MongoDB connector:

Now the block picker includes the new section:

Removing blocks from the Blocks Library

If a folder is removed from the Blocks Library folder and the block has been previously been used in a workflow, then this block is now unlinked from the master version on disk and will not experience any automatic updates. Blocks with these broken associations are marked with a special badge:

The blocks might be unlinked, but they are still executable just as they were when they were linked. In case it is necessary to update them, either the block needs to be restored in the blocks library folder, or the block needs to be converted into a standard Custom Block

Converting a Library Block to a standard Custom Block

Library Blocks have a special menu item called "Convert to Custom Block" accessible from the block dialog:

This is an action which can be undone and will convert to block into a custom block, thus enabling it to be edited again.

Block Library location on disk

In case the location next to the sharing folder is not suitable, a custom location can be chosen from within the admin menu section R&Python & Blocks Library

At the bottom of the section you find a selector with which a new folder can be chosen. The effect will only become active after a restart of the Omniscope Server.

Private company-wide Custom Block Repository

One specific use case of library blocks is to have a private repository in which Custom Blocks with proprietary code and functionality is stored and made available to all employees. This could for example be a private Github repository. The idea is to clone the repository to a place on disk and point the Block Library location to it. Whenever the remote repository is changed by adding new blocks or modifying existing ones, the local repository can be updated, which immediately propagates the changes to affected workflows and the block picker.