Sixty connectors at launch: the ERPs the business runs on, the planning applications that plan it, the warehouses and lakehouses that report on it, and the databases, files, streams and applications around them. Each connector page says how Lima reads or writes the system, which objects it covers, which patterns it supports and what to set up first. SAP connectors carry a compliance flag that names the interfaces used.
Use the search box for a system or a table name. The pattern toggles narrow the list to connectors that support full loads, incremental loads, change capture, streaming or write-back. The SAP-compliant toggle shows the connectors whose compliance statement names the interfaces used.
Systems of record: the ERP the business runs on. Sources for every pattern; targets for write-back.
Read SAP ECC through the interfaces SAP supports, and write results back through BAPIs and IDocs.
Read S/4HANA through released CDS views, table reads and BAPIs; write back with confirmation. On-premise, private cloud and RISE.
Read SAP BW and BW/4HANA data stores through Open Hub and released interfaces, for reporting history and migrations off BW.
Read Oracle EBS tables in parallel partitions with incremental capture, and write back through open interface tables and public APIs.
Read Oracle Fusion Cloud through BI Cloud Connector extracts and REST APIs; write back through REST and file-based import.
Read JD Edwards F-tables over JDBC with incremental capture; write back through the Orchestrator's REST services.
Read PeopleSoft records over JDBC and write back through Integration Broker services.
Read Dynamics 365 through data entities and the Dataverse; write back through OData entities.
Read Infor LN and M3 through ION APIs and business object documents; write back through the same interfaces.
Read NetSuite through SuiteAnalytics Connect and write back through SuiteTalk REST.
Targets that load a prepared planning dataset on a calendar and send plans back.
Load Kinaxis Maestro's linked tables in the right order, first in full and then as net change, and read the plan back for the ERP.
Load o9's planning graph member-first: dimensions and hierarchies, then measures at a grain, in a named version.
Load Blue Yonder's SKU and DFU model from one governed rule, with a single zero-filled history stream and aligned buckets.
Load SAP IBP planning areas: master data types, compound types and key figures at the planning level, in a time profile and version.
Load OMP's process-industry model: recipes with co- and by-products, unit conversions, batch characteristics, rates and tanks.
Load Anaplan lists and modules through the bulk integration API; read exports back for the ERP.
Targets for copies, history and analytics; also sources when the warehouse feeds another system.
Land data in Snowflake through stages and COPY INTO, keep it current with MERGE, and read it back when Snowflake feeds another system.
Land Delta tables in Unity Catalog in bronze, silver and gold layers, kept current with MERGE INTO.
Land Delta tables in a Fabric Lakehouse on OneLake, V-Ordered for Direct Lake in Power BI.
Land data in BigQuery through load jobs from Cloud Storage, partitioned and clustered, kept current with MERGE.
Land data in Redshift with COPY from S3 and apply changes through staging tables.
Land data in a Synapse dedicated SQL pool with COPY INTO from Data Lake Storage.
Read Teradata for migrations to a lakehouse and load it through bulk utilities when it stays the warehouse.
Files and open table formats on cloud storage; the landing zone for archives and migrations.
Land Parquet files in S3, partitioned by date, with optional Iceberg tables and Glue catalog registration.
Land Parquet or Delta files in ADLS Gen2 with the hierarchical namespace, ready for Synapse, Fabric and Databricks.
Land Parquet in Cloud Storage buckets read by BigQuery and BigLake external tables.
Read and write Parquet and ORC on on-premise Hadoop clusters, including Lima's own staging layer.
Write Apache Iceberg tables on object storage with snapshots, schema evolution and a catalog every engine can read.
Write Delta Lake tables on S3, ADLS or GCS with a transaction log, for Databricks, Fabric and Spark.
Operational and analytical databases read through JDBC, with change capture where the database offers it.
Read PostgreSQL in partitions, capture changes through logical replication, and load it as a target.
Read MySQL in partitions and capture changes from the binary log.
Read SQL Server in partitions, capture changes through CDC tables or change tracking, and load it as a target.
Read Oracle Database in parallel partitions and capture changes with LogMiner where the DBA allows.
Read Db2 for LUW, z/OS and i in partitions with incremental capture by change columns.
Read customer-owned schemas on SAP HANA over SQL, and load HANA as a target for custom applications.
Read MongoDB collections with schema inference and capture changes through change streams.
Read Aurora PostgreSQL and MySQL in partitions with native change capture.
Delimited, structured and spreadsheet files, arriving over SFTP or from document stores.
Pick up files by name pattern on a schedule or on arrival, load them, and archive or deliver files back.
Read delimited, JSON and XML files with schema inference, encodings and nested-structure flattening.
Read and write columnar and row files with schema evolution.
Read planning parameters, overrides and price lists from Excel workbooks with sheet and header rules.
Pick up files from SharePoint document libraries and OneDrive through the Microsoft Graph API.
Event streams, message queues, REST APIs and inbound webhooks.
Consume Kafka topics in micro-batches with offsets as checkpoints, and publish results back to topics.
Consume Kinesis shards in micro-batches with sequence numbers as checkpoints.
Consume Event Hubs through the Kafka-compatible endpoint or the native protocol.
Consume Pub/Sub subscriptions with acknowledgement as the checkpoint, and publish results.
Read and write any REST API from a configuration: authentication, endpoints, paging and retries, with the schema discovered on first connect.
Receive signed webhook payloads, queue them, and load them with replay when needed.
Cloud applications and procurement, HR and service systems.
Read Salesforce objects through the Bulk API and change events; write back through REST.
Read Workday through reports-as-a-service and the REST and SOAP APIs.
Read ServiceNow tables and create incidents from Lima exceptions, with the ticket number read back.
Read Coupa purchase orders, invoices and suppliers through its REST API, and post approved requisitions back.
Read SAP Ariba sourcing and procurement data through its released APIs.
WMS, carriers and 3PL feeds, and EDI documents.
Read Manhattan inventory, orders and shipments through APIs or agreed database reads, and send order instructions back.
Read Blue Yonder WMS inventory and orders through its interfaces and database, and send instructions back.
Read SAP EWM stock, tasks and deliveries through released interfaces, embedded or decentralised.
Read tracking, delivery and exception events from carriers and 3PLs through their APIs and EDI messages.
Translate EDI documents into rows and back: orders, acknowledgements, ship notices and invoices over AS2 or SFTP.
Targets that refresh when a load completes.
A pair page puts a source and a target together: which objects come out of the source, what the target expects, how the data is shaped between them, the checks that run before the load, and how the copy is kept current. The 150 pages at launch cover every ERP into every planning application and lakehouse; warehouse-management sources follow.
Built and supported by Lima. Every ERP, planning, warehouse, database, file and stream connector in this directory. Engineering reviews each page before it is published.
Core connectors going through a vendor certification program: Kinaxis, o9, Blue Yonder, Snowflake and Databricks. The status and its date are on each page; a badge appears only when it is granted.
The long tail of SaaS sources with small volumes. Lima routes these to a partner connector service and reads the result, so the request is met without promising a connector Lima would maintain poorly.
Every connector runs in all three deployment forms: Lima’s cloud, your private cloud, or on your own machines. Credentials are stored in a vault and referenced, never copied into a pipeline. A connection is tested before any pipeline is built, and a failed test names the cause. Each connector page lists its prerequisites so the people who run the source system know what to grant.
Tell us the system, the objects and the volume. Lima answers within five working days with one of three replies: the connector exists under another name, it is on the roadmap with a date, or it is routed to a partner connector. Request a connector →
Ask. Many systems are reached through the configurable REST or JDBC connectors under another name. If it needs a packaged connector Lima will build it when the volume and the number of customers justify it, and route it to a partner connector until then.
It means the connector reads SAP through interfaces SAP releases for the purpose: table reads through a named function module, BAPIs, CDS views, change pointers and extractor delta queues. It does not use the ODP RFC interface that SAP now blocks for third parties, and it installs nothing in SAP.
Yes. Kinaxis, o9, Blue Yonder, SAP IBP, OMP and Anaplan each have a connector page that describes the data model they expect and how Lima loads it, and pair pages from every ERP.
On the showcase estate five sources were connected in four days: SAP on day one, Oracle and the WMS on day two, Snowflake and the 3PL feeds on days three and four. The prerequisites on each page are what decide the pace.
A trial connects one source and one target and runs a first load with a reconciliation report. The prerequisites page tells your administrators what to grant.
