Konigi Inc - Data Automation and Migration Tools for Microsoft .Net, SQL Server and Cobol Environments

Database

Network

Cyber/Security

Supports SQL Server, Oracle and MySQL
Single Web Service Application account with EXECUTE as its only database privilege
Isolated developer/user access to the DB directly; no CRUD commands
Contributes towards eliminating SQL Injection (no EXEC or Dynamic SQL statements with this framework)
Reduces Security Management of databases by the DBA team
Generates “clean” SQL commands that adhere to rules (Keys, Indexes, Transactions, Foreign Keys)
Eliminates Dynamic SQL calls made by developers and other tools/applications
Eliminates Table Scans
Improves overall database performance
Promotes database Isolation levels
Incorporates Transaction control (Selectable)
Implements Error Logging (Selectable)
Accommodates Max Rows selected/returned (Selectable)
Eliminates Developer/End User Accounts
Promotes faster SDLC promotion (System Test, User Acceptance Testing, Staging, Production) and Deployment issues
Generates Unified, Standardized and Consistent Stored Procedure– Single Framework/Style with established table/field/index/key naming
Auto-cleanup of unused/orphan Stored Procedures upon DAL regeneration for project
Establishes a Single point of Data Security for database access
Exposes View and Custom Stored Procedures
Allows for generation of Stored Procedures with pre-defined Prefixes/Suffixes
Prevents intentional/inadvertent DB modifications by developers/end-users
Establishes a "No-Schema" foundation eliminating direct access by developers and users

Isolation for the DAL Web Application Server to single/dual ports (HTTP/HTTPS) or custom ports as required
No users performing SQL queries on SQL DB ports (1433); minimizes network traffic and improves overall performance
Enables Controlled points of monitoring for WS activity (HTTP/HTTPS)
Compliments integration with Message Queueing or Enterprise Service Bus technologies
Restricts access to Database and Web Service App Server to 2 systems (Firewall rules, Security Appliance)
Reduces monitoring endpoints (HTTP/HTTPS)
Minimizes intrusion points of ingress/egress
Promotes ease of transition between/to Cloud, Hybrid, BCP/DR and Clustered environments
Promotes deployment to BCP/DR, Cloud, or Hybrid sites

Isolation for the DAL Web Application Server to single/dual ports (HTTP/HTTPS) or custom ports as required
Promotes efficient monitoring (WS App Server and DB) via security appliances (F5, Cisco, etc.)
Web Services (WCF) are fully defined and automated (no user intervention)
Significantly reduces the impact of Malware on the DB/WS App Server
Security groups have confidence as the WS Code is non-accessible and can be isolated to the DBA team only
Eliminates provisioning developer/users for direct DB table access
Simplifies promotion between SDLC layers via minimal DB access accounts
Prevents developers/users from extracting or backing up a database
Promotes Data Governance and Monitoring for sensitive data
Implements best-practice controls for managing a Data Access Layer

Application Development (APP/DEV)

Development/Operations (DEV/OPS)

Other Key Features

Eliminates direct access to Database for the DEV team (No Schema Access philosophy)
Autogenerated WS endpoints allows for rapid integration with existing/new applications
Eliminates development resources required to design, develop, test, deploy, and maintain a Data Access Layer
Reduces development, testing, and the inherent delays of building, integrating, and testing of Web Service (WCF) interfaces and the impact of these areas on the project
No development staff is required to support the DAL code; DBA’s can own this technology.
Promotes isolation environment security and minimizes points of ingress/egress to the database and associated DAL endpoints
Eliminates “back-doors” into systems, and databases via Web API code and/or database functions, views, triggers or stored procedures
Faster to “Get-To-Data” for the App/Dev teams
Streamlines Business Logic Layer integration of UI to Data
SOAP Endpoints expose Strongly Typed Data (STD) via Extensible Schema Documents (XSD) and WSDL
WS provides SOAP endpoints configurable for XML, JSON, Datatables, or Datasets
WS provides REST endpoints configurable for XML, JSON (Query or URI) selectable
Data schemas changes can be accommodated rapidly via Project regeneration and deployment; Developers just “refresh” their service reference and implement the changes.
Promotes faster DB changes and minimizes regression and system testing requirements on data interfaces
Contributes to Micro-Service implementations with faster get-to-data frameworks
Generates, updates, compiles, and publishes Web Services from a user-create VS project
Provides Url ReWrite for simplifying extensionless URLs for Soap and Rest web services
Allows for usage of address or address-less web services (interfacing naming)

Allows for rapid provisioning of applications
Enables monitoring of events (WS App Writes to Windows Server Event Log for errors)
Single point of Ingress/Egress between Application and Data Tier
Standardizes Deployments
Establishes as single point for Account/Password control reduceing maintenance and security issues inherent with multiple DB and OS account
Developers are isolated from provisioning/deployments
Allows developers to consume DB changes rapidly opposed to waiting for extensive testing or relying on ADO, DB Factory, ODBC, JDBC technologies and using dynamic queries
Creates a unified point of access for all developers to maintain consistency across projects
Allows for rapid promotion between SDLC Hierarchies (Development, System Testing, User Acceptance Testing, Staging, Production)
Reduces code consolidation between DEV and SYSTEST, a critical point in code promotion
Eliminates Account cleanup, testing and validation between DEV and the upper SDLC layers
Enhances BCP/DR strategies and frameworks as data access is limited to HTTP/HTTPS ports
Publishes to an IIS site while mataining strict security and control of Web.Config

No API/DLL or other “external” code/applications required
All source code and stored procedures are fully editable and accessible
A single instance of DAL_GEN can support any number of databases and can generate any number of Web Service (WCF) solutions
Configurations are version controlled and re-selectable
History of build is maintained
Event logging fully supported
Cloud integration is fully supported (tested with Azure and AWS)
Fully compliant with .Net Framework 4.8 (can be updated to support lower versions)
Complainant with SQL Server 2012, 2014, 2016, and 2017
Promotes rapid Digital Transformation and/or Integration Initiatives
Code First, UI First strategies are key candidates for DAL_GEN
Contributes to Rapid-Application-Development (RAD) Strategies for R&D and Prototyping tasks
Generation can Build and Publish Solutions to IIS site(s)
Program level generation groups mulitple projects for simultanoues build/deployment and Publishing
Generation supports multi-site publising for Web Farms, BCP/DR and Standby Hot Sites


Database	Network	Cyber/Security
Supports SQL Server, Oracle and MySQL Single Web Service Application account with EXECUTE as its only database privilege Isolated developer/user access to the DB directly; no CRUD commands Contributes towards eliminating SQL Injection (no EXEC or Dynamic SQL statements with this framework) Reduces Security Management of databases by the DBA team Generates “clean” SQL commands that adhere to rules (Keys, Indexes, Transactions, Foreign Keys) Eliminates Dynamic SQL calls made by developers and other tools/applications Eliminates Table Scans Improves overall database performance Promotes database Isolation levels Incorporates Transaction control (Selectable) Implements Error Logging (Selectable) Accommodates Max Rows selected/returned (Selectable) Eliminates Developer/End User Accounts Promotes faster SDLC promotion (System Test, User Acceptance Testing, Staging, Production) and Deployment issues Generates Unified, Standardized and Consistent Stored Procedure– Single Framework/Style with established table/field/index/key naming Auto-cleanup of unused/orphan Stored Procedures upon DAL regeneration for project Establishes a Single point of Data Security for database access Exposes View and Custom Stored Procedures Allows for generation of Stored Procedures with pre-defined Prefixes/Suffixes Prevents intentional/inadvertent DB modifications by developers/end-users Establishes a "No-Schema" foundation eliminating direct access by developers and users	Isolation for the DAL Web Application Server to single/dual ports (HTTP/HTTPS) or custom ports as required No users performing SQL queries on SQL DB ports (1433); minimizes network traffic and improves overall performance Enables Controlled points of monitoring for WS activity (HTTP/HTTPS) Compliments integration with Message Queueing or Enterprise Service Bus technologies Restricts access to Database and Web Service App Server to 2 systems (Firewall rules, Security Appliance) Reduces monitoring endpoints (HTTP/HTTPS) Minimizes intrusion points of ingress/egress Promotes ease of transition between/to Cloud, Hybrid, BCP/DR and Clustered environments Promotes deployment to BCP/DR, Cloud, or Hybrid sites	Isolation for the DAL Web Application Server to single/dual ports (HTTP/HTTPS) or custom ports as required Promotes efficient monitoring (WS App Server and DB) via security appliances (F5, Cisco, etc.) Web Services (WCF) are fully defined and automated (no user intervention) Significantly reduces the impact of Malware on the DB/WS App Server Security groups have confidence as the WS Code is non-accessible and can be isolated to the DBA team only Eliminates provisioning developer/users for direct DB table access Simplifies promotion between SDLC layers via minimal DB access accounts Prevents developers/users from extracting or backing up a database Promotes Data Governance and Monitoring for sensitive data Implements best-practice controls for managing a Data Access Layer
Application Development (APP/DEV)	Development/Operations (DEV/OPS)	Other Key Features
Eliminates direct access to Database for the DEV team (No Schema Access philosophy) Autogenerated WS endpoints allows for rapid integration with existing/new applications Eliminates development resources required to design, develop, test, deploy, and maintain a Data Access Layer Reduces development, testing, and the inherent delays of building, integrating, and testing of Web Service (WCF) interfaces and the impact of these areas on the project No development staff is required to support the DAL code; DBA’s can own this technology. Promotes isolation environment security and minimizes points of ingress/egress to the database and associated DAL endpoints Eliminates “back-doors” into systems, and databases via Web API code and/or database functions, views, triggers or stored procedures Faster to “Get-To-Data” for the App/Dev teams Streamlines Business Logic Layer integration of UI to Data SOAP Endpoints expose Strongly Typed Data (STD) via Extensible Schema Documents (XSD) and WSDL WS provides SOAP endpoints configurable for XML, JSON, Datatables, or Datasets WS provides REST endpoints configurable for XML, JSON (Query or URI) selectable Data schemas changes can be accommodated rapidly via Project regeneration and deployment; Developers just “refresh” their service reference and implement the changes. Promotes faster DB changes and minimizes regression and system testing requirements on data interfaces Contributes to Micro-Service implementations with faster get-to-data frameworks Generates, updates, compiles, and publishes Web Services from a user-create VS project Provides Url ReWrite for simplifying extensionless URLs for Soap and Rest web services Allows for usage of address or address-less web services (interfacing naming)	Allows for rapid provisioning of applications Enables monitoring of events (WS App Writes to Windows Server Event Log for errors) Single point of Ingress/Egress between Application and Data Tier Standardizes Deployments Establishes as single point for Account/Password control reduceing maintenance and security issues inherent with multiple DB and OS account Developers are isolated from provisioning/deployments Allows developers to consume DB changes rapidly opposed to waiting for extensive testing or relying on ADO, DB Factory, ODBC, JDBC technologies and using dynamic queries Creates a unified point of access for all developers to maintain consistency across projects Allows for rapid promotion between SDLC Hierarchies (Development, System Testing, User Acceptance Testing, Staging, Production) Reduces code consolidation between DEV and SYSTEST, a critical point in code promotion Eliminates Account cleanup, testing and validation between DEV and the upper SDLC layers Enhances BCP/DR strategies and frameworks as data access is limited to HTTP/HTTPS ports Publishes to an IIS site while mataining strict security and control of Web.Config	No API/DLL or other “external” code/applications required All source code and stored procedures are fully editable and accessible A single instance of DAL_GEN can support any number of databases and can generate any number of Web Service (WCF) solutions Configurations are version controlled and re-selectable History of build is maintained Event logging fully supported Cloud integration is fully supported (tested with Azure and AWS) Fully compliant with .Net Framework 4.8 (can be updated to support lower versions) Complainant with SQL Server 2012, 2014, 2016, and 2017 Promotes rapid Digital Transformation and/or Integration Initiatives Code First, UI First strategies are key candidates for DAL_GEN Contributes to Rapid-Application-Development (RAD) Strategies for R&D and Prototyping tasks Generation can Build and Publish Solutions to IIS site(s) Program level generation groups mulitple projects for simultanoues build/deployment and Publishing Generation supports multi-site publising for Web Farms, BCP/DR and Standby Hot Sites