Learn more about

Producing the correct data is only part of an Ellucian Data Connect integration. The result also has to reach the receiving system in the format that system expects. A report, audit, or error file may require a specific delimiter, extension, header row, filename, or delivery destination. When multiple integrations need the same kinds of output […]

An Ellucian Data Connect pipeline may accept reason codes, employee classifications, or other runtime values that represent reference data maintained in Banner. These values cannot always be validated locally. A parameter may be present and have the correct format, but that still does not prove that the code actually exists in Banner or belongs to […]

Ellucian Data Connect is designed to support integrations that move and transform data between systems. Framework v3.1 is version 3.1 of Ellucian’s extensibility framework for Data Connect pre-built integrations. It provides reusable pipeline and sub-pipeline patterns, together with defined extension points for integration-specific behavior. The framework provides reusable baseline behavior for common integration concerns, so […]

Some Ellucian Data Connect pipelines need to process two related collections in sequence, but nested forEach loops are not supported. This post explains how to complete the first loop, preserve its payload, run a second loop, and merge the second-loop results back into the original records. It is part of our Ellucian Data Connect tips and implementation patterns series and belongs to its Pipeline […]

Reimplementing on-premises integration logic in Ellucian Data Connect is rarely a direct code conversion. Existing processes may rely on sequential operations, shared message state, runtime parameter rules, Banner reference data, report formatting, and file-delivery behavior that must be represented explicitly in a Data Connect pipeline. Over the past three years, the ABCloudz team has delivered […]

Migrating Oracle databases to PostgreSQL or MySQL with AWS Schema Conversion Tool (AWS SCT) can present a range of challenges, from unsupported data types to limitations in automated code conversion and potential performance issues. AWS SCT offers powerful capabilities to automate these migrations, but it may not always deliver optimal results or handle complex Oracle […]

Migrating databases from Oracle to Microsoft SQL Server can be a complex endeavor, especially when it comes to dealing with differences in schema structures, data types, and specific SQL clauses. The SQL Server Migration Assistant (SSMA) is a robust tool designed to automate these migrations and minimize manual effort. However, SSMA might not always produce […]

When migrating from Oracle to PostgreSQL, one of the most important differences to consider is the treatment of null and empty string values. In Oracle, null and empty string are treated as the same entity, but in PostgreSQL, they are distinct. Failing to account for this distinction during migration can lead to logical errors and […]

When working with PostgreSQL, database developers may encounter a limitation when attempting to create routines with more than 100 arguments. PostgreSQL enforces this restriction by setting FUNC_MAX_ARGS to 100 during the server build. Although this limitation is rarely an issue, complex procedures, particularly those migrated from Oracle, may have a significantly higher number of arguments. […]

Migrating databases from Oracle to SQL Server can be a daunting task, especially when dealing with date and time data. While tools like the SQL Server Migration Assistant (SSMA) offer automated solutions, relying solely on these tools might not always yield the best performance. In this blog, we share examples of how to optimize conversion […]

The AWS SCT Extension Pack is designed to emulate Oracle’s system functions, procedures, and other database objects within PostgreSQL. This emulation is achieved by creating a special schema in PostgreSQL, named aws_oracle_ext, where these functions and objects are stored. This pack simplifies migration by replacing Oracle-specific calls with their PostgreSQL equivalents, ensuring that the code […]

In this post we continue exploring the technical aspects of Oracle to PostgreSQL migration using AWS SCT. We were using AWS SCT build#660 to convert one of our Oracle test databases. AWS SCT provides functionalities for the most efficient migration from Oracle to PostgreSQL. However, there is a common challenge with implementing the Oracle NumToDSInterval […]

In this blog post we continue covering AWS SCT conversion issues, adding to the series where we help developers to deal with complex migration issues that can’t be automated with SCT. Today we are going to look into how SCT Build #660 addresses the conversion of statements with BULK COLLECT clause. In Oracle, you can […]

Here’s one more insight into common code conversion issues while using AWS SCT build number 660. This time, we will tell you how to convert NumToYmInterval from Oracle to MySQL. Oracle has a NumToYmInterval function that converts the provided number value of specified expressions or time units to an interval year to month literal. Usually, […]

In this post we continue exploring the technical aspects of Oracle to PostgreSQL migration using AWS SCT. AWS SCT promises a very high level of migration efforts, however it is very rare that 100% automation is achieved. In this article we’ll look into conversion of INSERT ALL statements, which are quite popular in Oracle code. […]