Oracle International Corporation

Jonathan Lopez Lopez

Juan Ignacio Vimberg

Ariel Cohen

Javier Espeche

Rajesh Tiwari

Rodolfo José Cruz

A layer of abstraction is provided for developing, configuring, displaying, selecting, and re-configuring connectors used through stages of predeployment, deployment, and post-deployment. A connector is created with the layer of abstraction, wherein the connector provides a first configuration of added functionality to software components for calling a web service. The connector is used to tie a step of a process-based software application to the web service. A different configuration of added functionality is provided for each of the stages of predeployment, deployment, and post deployment using the layer of abstraction.

Providing a different configuration of added functionality for each of the stages of predeployment, deployment, and post deployment using a layer of abstraction

An example system and method facilitates customization of and configuration of a software connector, such as a connector to an Application Programming Interface (API) or web service, in various types of computing environments, including both pre-deployment and post-deployment computing environments. A connectors framework provides a layer of abstraction between connectors maintained in the different environments and a connector editor of an application development system (which may be implemented via a server-side integrated development environment). The connector editor may provide User Interface (UI) functionality, including one or more UI controls for editing or otherwise modifying, customizing, and/or configuring connectors in pre-deployment and/or post deployment environments, which may represent or correspond to different connector and accompanying software development stages.

Pre/post deployment customization

Implementations provide a database lock mechanism used to prevent concurrent writes to service on network partition scenarios associated with a version control system. The database lock mechanism may be provided on per repository basis to ensure both nodes are working and maintaining data consistency, even when they are not connected when interruptions in network communication disrupts the intercommunication between nodes. In other implementations, the disclosed locking mechanism is configured to ensure and perform write and synchronization operations on isolated nodes, regardless of miss-communication between the nodes.

Network partition tolerance in a high available centralized VCS implementation

In one implementation, lightweight incremental backups are created by a data recovery tool, which provides an extra layer of protection against data loss, and also provides a way of moving repositories between databases without the need of copying each of the repositories. Implementations include backing up a distributed cluster of services providing a simple, safe, and convenient way of instantiating files system repositories in a database, thereby avoiding the performance and scalability issues of using a database repository itself. In other implementations, a lightweight backup object is created that includes a threshold amount of compressed information. The lightweight backup objects may be configured to provide the differences between revisions, and/or may be configured to replicate or rebuild the repository from scratch. Implementations may be configured to backup and restore any single or revision set in any repository state either online or offline.

Automatic disaster recovery mechanism for file-based version control system using lightweight backups

Implementations described herein provide a bidirectional tool configured to provide APIs to enable a cross-cluster service handshakes and design and implementation for enabling two or more instances of an application registered to one cluster and other cluster provides for multi environment interaction. Using a common service registration, users can trigger actions on different instances of the application running in different environments such as a development environment, production environment, and the like. Using the common registration, applications can scale by having extra instances running while a centralized service works as central hub were each instance is registered. Moreover, implementations include utilizing a plurality of deployment asset management layers to establish a stateless API instantiated between point-of-delivery server arrays employed to house multiple customers separated by security partitions.

Architectural design to enable bidirectional service registration and interaction among clusters

Implementations described herein provide a bidirectional tool configured to employ application program interfaces (APIs), cross-cluster service handshakes, and design and implementation enabling two or more instances of an application registered to one cluster and other clusters to provide multi environment interaction. Using a common service registration, users can trigger actions on different instances of the application running in different environments such as a development environment, production environment, and the like. Using the common registration, applications can scale by having extra instances running while a centralized service works as central hub were each instance is registered. Moreover, implementations include utilizing a plurality of deployment asset management layers to establish a stateless API instantiated between point-of-delivery server arrays employed to house multiple customers separated by security partitions.

Growing community of inventors

San Mateo, CA, United States of America

Jonathan Lopez Lopez