iLab integration

Home/Common/iLab integration

iLab integration

This package contains configuration and two plugins to interact with the iLab software. The integration allows capturing service requests generated by iLab into SLIMS. Once the laboratory work has been performed and recorded into SLIMS, the solution provides the work status back to iLab.

The package contains the following entities:

  • Five Custom fields on Order:
    • Update sent to iLab: A field of type Checkbox to indicate if the update has been pushed to iLab. An order with this field checked will not be considered for update anymore.
    • iLab Service ID: A field of type Short text to store the Id of the service (internal identifier). This field is automatically filled by the iLab plugin when the order is created.
    • iLab Service name: A field of type Short text to store the name of the service. This field is automatically filled by the iLab plugin when the order is created.
    • iLab Service Request ID: A field of type Short text to store the Id of the service request (internal identifier). This field is automatically filled by the iLab plugin when the order is created.
    • iLab Service Request Name: A field of type Short text to store the name of the service request. This field is automatically filled by the iLab plugin when the order is created.
  • Three Custom fields on Content:
    • iLab Sample ID: A field of type Short text to store the iLab sample id. It is filled by the iLab fetch request plugin when the content is created. This behavior can be changed in the iLabSamplesFieldHeaderSlimsMapper parameter of the Fetch iLab plugin.
    • iLab Sample Collection Date: A field of type Short text to store the iLab sample collection date. It is filled by the iLab fetch request plugin when the content is created. This behavior can be changed in the iLabSamplesFieldHeaderSlimsMapper parameter of the Fetch iLab plugin.
    • iLab Well Index: A field of type Short text to store the iLab well index. It is filled by the iLab fetch request plugin when the content is created. This behavior can be changed in the iLabSamplesFieldHeaderSlimsMapper parameter of the Fetch iLab plugin.
  • Two Plugins working on a corn expression as well as with a button in the Order module:
    • Fetch iLab Requests: The plugin looks for new service requests in iLab and creates an order for each requested service. It also creates samples and links
    • them to the orders. Optionally,  the plugin can map services to SLIMS requestables for non-analytical workflows.
    • Update iLab Requests: For each completed SLIMS order, the corresponding service in iLab is updated.
  • One Order Type:
    • iLab Order: Order type of type Workflow orders used by the plugins to identify iLab orders/requests.
  • One Content Type:
    • Sample: A generic content type used by the plugin as a default sample type when the Content type specified by iLab cannot be found in SLIMS.

How to use the package

Pre-requisite

SLIMS:

The relevant workflows and requestables have been configured.

The relevant content types have been created or imported. Also, the content type and content status used as default values by the Fetch iLab Requests plugin should exist and be active in SLIMS.

SLIMS GATE must be running.

iLab:

The iLab API version 1 should be enabled.

The iLab instance must contain at least one Project Template containing:

  • a Custom Form used to record the samples information. This custom form should contain
    • a dropdown query field that identifies the sample type
    • a conditional grid that matches the selected sample type used to collect sample information passed to SLIMS.
  • a Milestone which name must be the same across all projects in the core that will be sent to SLIMS (e.g. SLIMS, LIMS processing, etc.)
  • one or several services

The Custom Form name, the sample type dropdown field name, the possible sample type values, the conditional grid detail (headers), the milestone name, and the service names must be provided to the SLIMS team.

Please contact your local iLab team for any questions regarding the required iLab setup.

Configuration

The plugin configurations contain parameters that require adaptation as well as parameters that are optional to be adjusted.

Fetch iLab Requests:

Parameters requiring adaptation:
  • iLabApiHostname: the hostname of the iLab core to connect to
  • iLabCoreId: the ID of the iLab core to connect to
  • iLabApiBearerToken: the bearer token used for authorization in calls to the iLab REST iLabApiBearerToken
  • iLabSlimsMilestone: milestone name used to track order creation in SLIMS
  • iLabSamplesFormName: custom form name used in iLab to record samples information
  • iLabSampleTypeSelectionFieldIdentifier: field name in the custom form used in iLab to record samples type
  • iLabSampleTypeSlimsContentTypeUIDMapper: mapper between iLab sample type and SLIMS content type unique identifier
  • slimsRoleToReceiveNotificationsUID: which role’s users will receive SLIMS notifications if updates to iLab fail
  • iLabSamplesFieldHeaderSlimsMapper: mapper of fields between iLab samples field grid and SLIMS fields
  • iLabServiceNameToSlimsRequestableUniqueIdentifierMapper: mapper of iLab service names to SLIMS requestables. This mapping is restricted in use for workflow orders Order Type (defined above with the iLabOrderOrderTypeUID parameter) and non-analytical requestables (defined in the Workflow Management module).
Optional adjustments :
  • cronExpressionForILabUpdates: time interval to check for SLIMS orders that should be updated in iLab (default: “0+0/5+*+*+*+?”; every 5 minutes)
  • iLabServiceRequestStatusNamesToFetch: statuses of service requests that should be fetched (default: “Processing”)
  • timeZoneToUseForSettingILabDateTimeFields: the timezone to use when setting datetimes in iLab, for example the milestone startedOn datetime
  • errorNotificationTitle: title to use for SLIMS notifications if imports from iLab fail
  • iLabServiceRequestIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the service request that this order is associated with
  • iLabServiceRequestNameOrderFieldName: The SLIMS order field of type Short text to fill with the name of the service request that this order is associated with
  • iLabServiceIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the individual service that this order is associated with
  • iLabServiceNameOrderFieldName: The SLIMS order field of type Short text to fill with the name of the individual service that this order is associated with
  • iLabOrderOrderTypeUID: The SLIMS order type unique identifier used to create iLab orders
  • defaultContentStatusUniqueIdentifier: unique identifier of default content status set for all created contents
  • defaultContentTypeUniqueIdentifier: unique identifier of default content types set for all created contents

Update iLab Requests:

Parameters requiring adaptation:
  • slimsUrl: base SLIMS URL of this instance (used when generating links to orders)
  • iLabApiHostname: the hostname of the iLab core to connect to
  • iLabApiBearerToken: the bearer token used for authorization in calls to the iLab REST iLabApiBearerToken
  • iLabCoreId: the ID of the iLab core to connect to
  • iLabSlimsMilestone: milestone name used to track order creation in SLIMS
  • slimsRoleToReceiveNotificationsUID: which role’s users will receive SLIMS notifications if updates to iLab fail
Optional adjustments :
  • cronExpressionForIlabUpdates: time interval to check for SLIMS orders that should be updated in iLab (default: “0+0/5+*+*+*+?”; every 5 minutes)
  • errorNotificationTitle: title to use for SLIMS notifications if updates to iLab fail
  • orderUpdateSentToILabFieldName: the SLIMS order field of type Checkbox that indicates whether updates have already been sent for that order
  • slimsOrderTypeToBeUpdatedInILabUID: the type of SLIMS order that should have updates sent to iLab
  • slimsOrderStatusesToTriggerUpdatesInILabUIDs: the SLIMS order statuses that should trigger updates to be sent to iLab
  • iLabServiceRequestIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the service request that this order is associated with
  • iLabServiceIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the individual service that this order is associated with
  • iLabCompletedStatus: the name of the work status in iLab that the service/charge should be updated to
  • iLabReadyToBillStatus: the name of the billing status in iLab that the service/charge should be updated to
  • timeZoneToUseForSettingIlabDateTimeFields: the timezone to use when setting datetimes in iLab, for example the milestone startedOn datetime

Step by step usage

  1. A service request is initiated in iLab. This service request contains a list of samples and a milestone which name matches one of the Fetch iLab Requests plugin configuration (parameter: iLabSlimsMilestone).
  2. The first plugin – Fetch iLab Requests – starts and creates the orders (one per service contained in the service request) in SLIMS. The iLab samples are created as contents and linked to the newly created orders.
  3. If the iLab order type specified in the plugin configuration (iLabOrderOrderTypeUID) is of type “Workflow” and if the service name is contained in the parameter used to map iLab service names to SLIMS requestable (IlabServiceNameToSlimsRequestableUniqueIdentifierMapper), a request is created for each content in the current order.
  4. In iLab the description of the SLIMS milestone is updated with a message containing the list of SLIMS order barcodes created during the process. Also, the “started_on” field of the SLIMS milestone is set to the current date-time. This automatically modifies the status of the milestone to “Started”.
  5. If any exception is thrown during a bean in the route, a SLIMS notification is created with the error message and is sent to a group of users based on their role (slimsRoleToReceiveNotificationsUID).
  6. The orders are processed in SLIMS (i.e. contents are sent through workflows and processed in the protocols).
  7. Once the requests/orders are processed, the second plugin – Update iLab Requests – fetches all orders with statuses matching configuration parameter (slimsOrderStatusesToTriggerUpdatesInILabUIDs) AND the checkbox field containing the flag if an update has already been sent to iLab (orderUpdateSentToILabFieldName) is unchecked AND order type matches config parameters (slimsOrderTypeToBeUpdatedInILabUID)
  8. For each order, the plugin updates the corresponding service in iLab (the charge ID – iLabServiceIdOrderFieldName – and the service request ID – iLabServiceRequestIdOrderFieldName are stored on the SLIMS order) with appropriate statuses (iLabCompletedStatus and iLabReadyToBillStatus). If all the charges/services for a given service request are completed, the “completed_on” field of the SLIMS milestone is set to the current date-time. This automatically modifies the status of the milestone to “Finished”.
  9. If the updates succeed, the field orderUpdateSentToILabFieldName is set to true for each order.
  10. If any exception is thrown during a bean in the route, a SLIMS notification is created with the error message and is sent to a group of users based on their role (slimsRoleToReceiveNotificationsUID).

Where to Look Next

These references have further information on how to configure or use the package contents after the initial installation and integration.

  • SLIMS Administration Manual:
    • Content Management > Content types
    • Miscellaneous > Plugins Module
    • Miscellaneous > Fields > Custom Fields
    • Order Management > Order Type
    • Order Management > Orders
    • Workflows > Workflow Management
    • Workflows > SLIMS-NGS
Category: Tags: , ,

Description

This package contains configuration and two plugins to interact with the iLab software. The integration allows capturing service requests generated by iLab into SLIMS. Once the laboratory work has been performed and recorded into SLIMS, the solution provides the work status back to iLab.

The package contains the following entities:

  • Five Custom fields on Order:
    • Update sent to iLab: A field of type Checkbox to indicate if the update has been pushed to iLab. An order with this field checked will not be considered for update anymore.
    • iLab Service ID: A field of type Short text to store the Id of the service (internal identifier). This field is automatically filled by the iLab plugin when the order is created.
    • iLab Service name: A field of type Short text to store the name of the service. This field is automatically filled by the iLab plugin when the order is created.
    • iLab Service Request ID: A field of type Short text to store the Id of the service request (internal identifier). This field is automatically filled by the iLab plugin when the order is created.
    • iLab Service Request Name: A field of type Short text to store the name of the service request. This field is automatically filled by the iLab plugin when the order is created.
  • Three Custom fields on Content:
    • iLab Sample ID: A field of type Short text to store the iLab sample id. It is filled by the iLab fetch request plugin when the content is created. This behavior can be changed in the iLabSamplesFieldHeaderSlimsMapper parameter of the Fetch iLab plugin.
    • iLab Sample Collection Date: A field of type Short text to store the iLab sample collection date. It is filled by the iLab fetch request plugin when the content is created. This behavior can be changed in the iLabSamplesFieldHeaderSlimsMapper parameter of the Fetch iLab plugin.
    • iLab Well Index: A field of type Short text to store the iLab well index. It is filled by the iLab fetch request plugin when the content is created. This behavior can be changed in the iLabSamplesFieldHeaderSlimsMapper parameter of the Fetch iLab plugin.
  • Two Plugins working on a corn expression as well as with a button in the Order module:
    • Fetch iLab Requests: The plugin looks for new service requests in iLab and creates an order for each requested service. It also creates samples and links
    • them to the orders. Optionally,  the plugin can map services to SLIMS requestables for non-analytical workflows.
    • Update iLab Requests: For each completed SLIMS order, the corresponding service in iLab is updated.
  • One Order Type:
    • iLab Order: Order type of type Workflow orders used by the plugins to identify iLab orders/requests.
  • One Content Type:
    • Sample: A generic content type used by the plugin as a default sample type when the Content type specified by iLab cannot be found in SLIMS.

How to use the package

Pre-requisite

SLIMS:

The relevant workflows and requestables have been configured.

The relevant content types have been created or imported. Also, the content type and content status used as default values by the Fetch iLab Requests plugin should exist and be active in SLIMS.

SLIMS GATE must be running.

iLab:

The iLab API version 1 should be enabled.

The iLab instance must contain at least one Project Template containing:

  • a Custom Form used to record the samples information. This custom form should contain
    • a dropdown query field that identifies the sample type
    • a conditional grid that matches the selected sample type used to collect sample information passed to SLIMS.
  • a Milestone which name must be the same across all projects in the core that will be sent to SLIMS (e.g. SLIMS, LIMS processing, etc.)
  • one or several services

The Custom Form name, the sample type dropdown field name, the possible sample type values, the conditional grid detail (headers), the milestone name, and the service names must be provided to the SLIMS team.

Please contact your local iLab team for any questions regarding the required iLab setup.

Configuration

The plugin configurations contain parameters that require adaptation as well as parameters that are optional to be adjusted.

Fetch iLab Requests:

Parameters requiring adaptation:
  • iLabApiHostname: the hostname of the iLab core to connect to
  • iLabCoreId: the ID of the iLab core to connect to
  • iLabApiBearerToken: the bearer token used for authorization in calls to the iLab REST iLabApiBearerToken
  • iLabSlimsMilestone: milestone name used to track order creation in SLIMS
  • iLabSamplesFormName: custom form name used in iLab to record samples information
  • iLabSampleTypeSelectionFieldIdentifier: field name in the custom form used in iLab to record samples type
  • iLabSampleTypeSlimsContentTypeUIDMapper: mapper between iLab sample type and SLIMS content type unique identifier
  • slimsRoleToReceiveNotificationsUID: which role’s users will receive SLIMS notifications if updates to iLab fail
  • iLabSamplesFieldHeaderSlimsMapper: mapper of fields between iLab samples field grid and SLIMS fields
  • iLabServiceNameToSlimsRequestableUniqueIdentifierMapper: mapper of iLab service names to SLIMS requestables. This mapping is restricted in use for workflow orders Order Type (defined above with the iLabOrderOrderTypeUID parameter) and non-analytical requestables (defined in the Workflow Management module).
Optional adjustments :
  • cronExpressionForILabUpdates: time interval to check for SLIMS orders that should be updated in iLab (default: “0+0/5+*+*+*+?”; every 5 minutes)
  • iLabServiceRequestStatusNamesToFetch: statuses of service requests that should be fetched (default: “Processing”)
  • timeZoneToUseForSettingILabDateTimeFields: the timezone to use when setting datetimes in iLab, for example the milestone startedOn datetime
  • errorNotificationTitle: title to use for SLIMS notifications if imports from iLab fail
  • iLabServiceRequestIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the service request that this order is associated with
  • iLabServiceRequestNameOrderFieldName: The SLIMS order field of type Short text to fill with the name of the service request that this order is associated with
  • iLabServiceIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the individual service that this order is associated with
  • iLabServiceNameOrderFieldName: The SLIMS order field of type Short text to fill with the name of the individual service that this order is associated with
  • iLabOrderOrderTypeUID: The SLIMS order type unique identifier used to create iLab orders
  • defaultContentStatusUniqueIdentifier: unique identifier of default content status set for all created contents
  • defaultContentTypeUniqueIdentifier: unique identifier of default content types set for all created contents

Update iLab Requests:

Parameters requiring adaptation:
  • slimsUrl: base SLIMS URL of this instance (used when generating links to orders)
  • iLabApiHostname: the hostname of the iLab core to connect to
  • iLabApiBearerToken: the bearer token used for authorization in calls to the iLab REST iLabApiBearerToken
  • iLabCoreId: the ID of the iLab core to connect to
  • iLabSlimsMilestone: milestone name used to track order creation in SLIMS
  • slimsRoleToReceiveNotificationsUID: which role’s users will receive SLIMS notifications if updates to iLab fail
Optional adjustments :
  • cronExpressionForIlabUpdates: time interval to check for SLIMS orders that should be updated in iLab (default: “0+0/5+*+*+*+?”; every 5 minutes)
  • errorNotificationTitle: title to use for SLIMS notifications if updates to iLab fail
  • orderUpdateSentToILabFieldName: the SLIMS order field of type Checkbox that indicates whether updates have already been sent for that order
  • slimsOrderTypeToBeUpdatedInILabUID: the type of SLIMS order that should have updates sent to iLab
  • slimsOrderStatusesToTriggerUpdatesInILabUIDs: the SLIMS order statuses that should trigger updates to be sent to iLab
  • iLabServiceRequestIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the service request that this order is associated with
  • iLabServiceIdOrderFieldName: The SLIMS order field of type Short text to fill with the ID of the individual service that this order is associated with
  • iLabCompletedStatus: the name of the work status in iLab that the service/charge should be updated to
  • iLabReadyToBillStatus: the name of the billing status in iLab that the service/charge should be updated to
  • timeZoneToUseForSettingIlabDateTimeFields: the timezone to use when setting datetimes in iLab, for example the milestone startedOn datetime

Step by step usage

  1. A service request is initiated in iLab. This service request contains a list of samples and a milestone which name matches one of the Fetch iLab Requests plugin configuration (parameter: iLabSlimsMilestone).
  2. The first plugin – Fetch iLab Requests – starts and creates the orders (one per service contained in the service request) in SLIMS. The iLab samples are created as contents and linked to the newly created orders.
  3. If the iLab order type specified in the plugin configuration (iLabOrderOrderTypeUID) is of type “Workflow” and if the service name is contained in the parameter used to map iLab service names to SLIMS requestable (IlabServiceNameToSlimsRequestableUniqueIdentifierMapper), a request is created for each content in the current order.
  4. In iLab the description of the SLIMS milestone is updated with a message containing the list of SLIMS order barcodes created during the process. Also, the “started_on” field of the SLIMS milestone is set to the current date-time. This automatically modifies the status of the milestone to “Started”.
  5. If any exception is thrown during a bean in the route, a SLIMS notification is created with the error message and is sent to a group of users based on their role (slimsRoleToReceiveNotificationsUID).
  6. The orders are processed in SLIMS (i.e. contents are sent through workflows and processed in the protocols).
  7. Once the requests/orders are processed, the second plugin – Update iLab Requests – fetches all orders with statuses matching configuration parameter (slimsOrderStatusesToTriggerUpdatesInILabUIDs) AND the checkbox field containing the flag if an update has already been sent to iLab (orderUpdateSentToILabFieldName) is unchecked AND order type matches config parameters (slimsOrderTypeToBeUpdatedInILabUID)
  8. For each order, the plugin updates the corresponding service in iLab (the charge ID – iLabServiceIdOrderFieldName – and the service request ID – iLabServiceRequestIdOrderFieldName are stored on the SLIMS order) with appropriate statuses (iLabCompletedStatus and iLabReadyToBillStatus). If all the charges/services for a given service request are completed, the “completed_on” field of the SLIMS milestone is set to the current date-time. This automatically modifies the status of the milestone to “Finished”.
  9. If the updates succeed, the field orderUpdateSentToILabFieldName is set to true for each order.
  10. If any exception is thrown during a bean in the route, a SLIMS notification is created with the error message and is sent to a group of users based on their role (slimsRoleToReceiveNotificationsUID).

Where to Look Next

These references have further information on how to configure or use the package contents after the initial installation and integration.

  • SLIMS Administration Manual:
    • Content Management > Content types
    • Miscellaneous > Plugins Module
    • Miscellaneous > Fields > Custom Fields
    • Order Management > Order Type
    • Order Management > Orders
    • Workflows > Workflow Management
    • Workflows > SLIMS-NGS

Additional information

packages

VERSION_6_7:532, VERSION_6_8:604

Title

Go to Top