Abstract: A system is provided for automatically generating electronic artifacts using extended functionality. In particular, the system may use a template-based process to automatically generate artifacts based on a defined set of parameters and/or variables. The system may further use one or more plugins which may provide extended functionality with respect to the artifact generation process. Accordingly, the artifact generation process may include initializing a parameter list based on application parameters and/or plugin parameters, processing the parameters, generating variables based on the parameters, and replacing variables in scheme template files with appropriate values (e.g., user supplied or plugin generated values) to output an artifact file to a predetermined location. In this way, the system provides a robust and efficient way to automatically generate artifacts.

Abstract: A system is provided for automatically generating electronic artifacts using extended functionality. In particular, the system may use a template-based process to automatically generate artifacts based on a defined set of parameters and/or variables. The system may further use one or more plugins which may provide extended functionality with respect to the artifact generation process. Accordingly, the artifact generation process may include initializing a parameter list based on application parameters and/or plugin parameters, processing the parameters, generating variables based on the parameters, and replacing variables in scheme template files with appropriate values (e.g., user supplied or plugin generated values) to output an artifact file to a predetermined location. In this way, the system provides a robust and efficient way to automatically generate artifacts.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: Apparatus and methods may include a method for validating a script. The script may be a script for firing a job in an Autosys™ application deployed in a predetermined environment. The validating may use a validation system. The method may include providing a plurality of pre-deployment validation utility actions. The plurality of pre-deployment utility actions may include permitting only insert (INS), update (UPD) and delete (DEL) as actions in the script. The permitting may use an action name review utility. The plurality of pre-deployment utility actions may include permitting only command (CMD) or box parameter types (BMT) in the script. The permitting may use a parameter type review utility. The plurality of pre-deployment utility actions may include specifying only NULL, FDR and LMCTR as project codes. The specifying may use a project code specifier utility.

Abstract: Apparatus and methods may include a method for enabling customized jobs deployment in Autosys™, reviewing of execution results of the jobs in Autosys™, and querying the execution results. The method may include providing a verification of the deployment of a plurality of job scripts in a staging area. The staging area may be configured for arranging and deploying a plurality of job scripts in Autosys™. The method may include visually indicating, in a status line, whether each of the plurality of job scripts has been deployed in Autosys™ or is set to be deployed to, and executed in, Autosys™. The method may include importing selected contents of a log folder from Autosys™. The importing may use an import utility.

Abstract: Current systems for synchronizing multiple database systems suffer from technical drawbacks. For example, archive jobs run on a second database system are typically started independently of operational jobs that are run on a first database system and generate the output data that needs to be archived. The lack of synchronization between first and second database systems delays access to the output data from within the second database system. Apparatus and methods described herein synchronize migration of output data generated by a first database system into a second database system, despite incompatibility between the first and second database systems. Apparatus and methods may synchronize the second database system such that it archives output data generated by the first database system within a target time of successful generation of output data by the first database system.

Abstract: Apparatus and methods may include a method for using a single script framework to generate a plurality of JIL files. Each of the plurality of JIL files may be for use in one of a plurality of multiple environments. The methods may include providing, based on the jobs information, the jobs attribute values and the SQL content, parameters to create a job, update a job and/or delete a job. The providing may use an AutoSys™ jobs table. The AutoSys™ jobs table may include jobs information, jobs attribute values, and Sequel (SQL) content to be run.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: A system is provided for automatically generating electronic artifacts using extended functionality. In particular, the system may use a template-based process to automatically generate artifacts based on a defined set of parameters and/or variables. The system may further use one or more plugins which may provide extended functionality with respect to the artifact generation process. Accordingly, the artifact generation process may include initializing a parameter list based on application parameters and/or plugin parameters, processing the parameters, generating variables based on the parameters, and replacing variables in scheme template files with appropriate values (e.g., user supplied or plugin generated values) to output an artifact file to a predetermined location. In this way, the system provides a robust and efficient way to automatically generate artifacts.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: Current systems for synchronizing multiple database systems suffer from technical drawbacks. For example, archive jobs run on a second database system are typically started independently of operational jobs that are run on a first database system and generate the output data that needs to be archived. The lack of synchronization between first and second database systems delays access to the output data from within the second database system. Apparatus and methods described herein synchronize migration of output data generated by a first database system into a second database system, despite incompatibility between the first and second database systems. Apparatus and methods may synchronize the second database system such that it archives output data generated by the first database system within a target time of successful generation of output data by the first database system.

Abstract: Apparatus and methods may include a method for enabling customized jobs deployment in Autosys TM, reviewing of deployment results of said jobs in Autosys TM, and querying said deployment results. The method may include providing a verification of the deployment in a staging area. The staging area may be configured for arranging and deploying a plurality of job scripts in Autosys TM. Each job script may be interrelated with one or more other job scripts. The method may include visually indicating, in a status line, whether the job script has been deployed in Autosys TM or is set to be deployed to Autosys TM. The method may include further visually indicating in what way the job script is interrelated with one or more other job scripts. The method may include importing selected contents of a log folder from Autosys TM.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: In entity transition from legacy systems to a big data distributed data platform, numerous system-based architectural gaps have surfaced. There exists a need for a bridge component for each of the architectural gaps in order to support the entity transition to the big data distributed data platform. These bridge components include a variety of frameworks that are configured to automate certain processes that are needed for the transition. These processes have only become necessary as a result of the Hadoop platform. The automated processes include a snapshot load platform. The snapshot load platform enables the addition of a new view to the historical tables. The platform includes replacing the entire table in a truncated scenario. The platform includes replacing cases in a refresh or update scenario.

Abstract: Apparatus and methods may include a method for enabling customized jobs deployment in Autosys TM, reviewing of deployment results of said jobs in Autosys TM, and querying said deployment results. The method may include providing a verification of the deployment in a staging area. The staging area may be configured for arranging and deploying a plurality of job scripts in Autosys TM. Each job script may be interrelated with one or more other job scripts. The method may include visually indicating, in a status line, whether the job script has been deployed in Autosys TM or is set to be deployed to Autosys TM. The method may include further visually indicating in what way the job script is interrelated with one or more other job scripts. The method may include importing selected contents of a log folder from Autosys TM.

Abstract: Apparatus and methods may include a method for using a single script framework to generate a plurality of JIL files. Each of the plurality of JIL files may be for use in one of a plurality of multiple environments. The methods may include providing, based on the jobs information, the jobs attribute values and the SQL content, parameters to create a job, update a job and/or delete a job. The providing may use an AutoSys™ jobs table. The AutoSys™ jobs table may include jobs information, jobs attribute values, and Sequel (SQL) content to be run.

Abstract: Apparatus and methods may include a method for validating a script. The script may be a script for firing a job in an Autosys TM application deployed in a predetermined environment. The validating may use a validation system. The method may include providing a plurality of pre-deployment validation utility actions. The plurality of pre-deployment utility actions may include permitting only insert (INS), update (UPD) and delete (DEL) as actions in the script. The permitting may use an action name review utility. The plurality of pre-deployment utility actions may include permitting only command (CMD) or box parameter types (BMT) in the script. The permitting may use a parameter type review utility. The plurality of pre-deployment utility actions may include specifying only NULL, FDR and LMCTR as project codes. The specifying may use a project code specifier utility.