ESB

 An enterprise service bus (ESB) is a bus-like architecture that helps integrate diverse applications and services in an enterprise. 

It incorporates a messaging engine, data integration and routing capabilities, web services, and analytics capabilities. 

You can use an ESB for the following:

• Decouple product components and allocate them to different compute resources
• Support migration between servers, private and public clouds, and hybrid cloud environments
• Support loose coupling - thereby enabling you to readily integrate existing systems and incorporate new technologies as they emerge
• Creation of new web services and functions seamlessly with in-built message brokering
• Build solutions with visual tooling, interactive debugging, and data mapping
• Analyze integration flows with advanced, customizable analytics capabilities

ESB’s guiding principles are:

• Orchestration - integrates two or more applications and services to synchronize data and process.
• Transformation - transforms data from canonical to application specific format.
• Transportation - protocol negotiation between multiple formats like HTTP, JDBC, JMS, and FTP etc.
• Mediation - multiple interfaces for supporting multiple versions of a service.
• Non-functional consistency - transaction management and security.

Below are some of the ESB products:

• Red Hat JBoss Fuse. 
• Mule ESB. 
• IBM Websphere ESB.
• Oracle ESB.
• Microsoft BizTalk.
• IBM DataPower Gateway

Salesforce Sandbox Types

 The development and testing environment within Salesforce is termed as Salesforce Sandbox. The sandbox copy of Salesforce is provisioned with all code, data, and configuration.

 Salesforce Sandbox is not a separate version of the organization, instead, it is just a replica of the original one. Any change in the organization will not be automatically reflected in Salesforce Sandbox.

 A snapshot of the production environment on the date on which it is created is known as Salesforce Sandbox.

The Sandbox environment is created for several purposes like for training, development, testing, and others, even without affecting data and configuration in the Salesforce production instance.

Sandbox Types:

Developer Sandbox:

A Developer sandbox is intended for development and testing in an isolated environment. A Developer Sandbox includes a copy of your production org’s configuration (metadata).

Points to remember:

1)Storage limit is 200MB.

2)Refreshing limits is once per day.

Developer Pro Sandbox:

A Developer Pro sandbox is intended for development and testing in an isolated environment and can host larger data sets than a Developer sandbox. 

A Developer Pro sandbox includes a copy of your production org’s configuration (metadata). Use a Developer Pro sandbox to handle more development and quality assurance tasks and for integration testing or user training.

Points to remember:

1)Refresh limit is once per day.

2)Storage limit is of Max 1GB.

Partial Copy Sandbox:

A Partial Copy sandbox is intended to be used as a testing environment. This environment includes a copy of your production org’s configuration (metadata) and a sample of your production org’s data as defined by a sandbox template. 

Use a Partial Copy sandbox for quality assurance tasks such as user acceptance testing, integration testing, and training.

Points to remember:

1)You can refresh a Partial Data sandbox 5 days after you created or last refreshed it

2) If you delete a Partial Data sandbox within those 5 days, you need to wait until after the 5 day period, from the date of last refresh or creation, to replace it.

3)Storage limit is of Max 5GB and and maximum 10,000 record per selected object..

Full Copy Sandbox:

A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and staging. Full sandboxes are a replica of your production org, including all data, such as object records and attachments, and metadata.

When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.

The default is to omit field tracking, but you can include up to 180 days of field tracking. If you track field history for many objects in your production org, specify fewer days to avoid generating an excessive amount of data.

Points to remember:

1)You can refresh a Full sandbox 29 days after you created or last refreshed it.

2) If you delete a Full sandbox within those 29 days, you need to wait until after the 29 day period, from the date of last refresh or creation, to replace it.

3)Storage limits are Same like prod Sandbox.

Monitoring Jenkins with Java Melody

Jenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software.”

Jenkins is written in Java (making it an ideal candidate to be monitored by Instana) and can be extended via plugins. 

There are thousands of plugins, created and maintained by the community, that provide a range of functionality from unit testing, to security, to compliance reporting.

There is a monitoring plugin for Jenkins that provides a lot of data about what’s going on within Jenkins and about the tasks being performed by Jenkins. The Jenkins monitoring plugin relies on JavaMelody which is a basic metric charting tool. 

JavaMelody is an open source application used to monitor Java or Java EE application servers.

It measures and calculates statistical information based on application usage. The resulting data can be viewed in a variety of formats including evolution charts, which track various operations and server attributes over time. 

There are also robust reporting options that allow data to be exported in either HTML of PDF formats.

For Demo, Please refer below video:

WebDriverIO Introduction

Webdriver.io is a mobile and browser test automation framework that has recently become quite popular in the software testing industry. 

This free and open-source framework is written in JavaScript and runs on Node.js. Packaged into npm, WebdriverIO is easy to install and use. This framework enables you to test web applications as well as native mobile apps.

Webdriver is popular because it is backed by Selenium which means you can run test scripts on all browsers. While it brings all the advantages of Selenium, it eliminates the pain of writing Java-based scripts.

 It allows you to easily integrate it with multiple testing frameworks such as Appium to bring the best out of both worlds.

The Key Features of WebDriverIO:

• Run automation tests both for web applications as well as native mobile apps
• Simple and Easy Syntax
• Integrating tests to third-party tools such as Appium.
• ‘Wdio setup wizard’ to make the setup simple and easy.
• Integrated test runner

WebDriverIO Vs Selenium WebDriver

Both WebDriverIO and Selenium WebDriver are open source and are used for browser testing. Selenium is used for automating browsers, while WebDriverIO is used for automating both browsers and native mobile apps.

Prerequisites For Setting Up WebDriverIO

• You need to install NodeJS in your machine before setting up WebDriverIO.
• Additionally, you’ll need to install VSCode IDE
• To install WebDriverIO CLI, execute the below command in the terminal.      npm i --save-dev @wdio/cli

Introduction to WebLogic Scripting Tool

The WebLogic Scripting Tool (WLST) is a command-line scripting interface that the weblogic administrators and operators use to monitor and manage WebLogic Server instances and domains.

It can replace configuration wizard, template builder, command line deployment: weblogic.Deployer, admin console.

WLST is a tool which is based on the Python programming language and uses the Jython feature to act as an administrator interface of the WebLogic Server.

WLST modes

WLST can be used in several modes; we can however group them in the following main three categories:

Offline: Mostly used to create new domains like the configuration domain wizard

Online: Used to perform online administration tasks just like the Administration console

Embedded: Invoked directly from Java code

Sample HelloWorld Program:

import sys

if len(sys.argv) > 1:

    print sys.argv[1]+" from the console" 

else:

    print "Hello World from the script

From Shell:

java weblogic.WLST HelloWorld.py "Hello World"

Time-Based One Time Password

Conventional passwords – however strong the user makes them – have a disadvantage: if somebody else knows the character string, security is no longer guaranteed. One solution would be to change passwords regularly, but even the most exemplary users do not do this every hour. 

The solution is a TOTP.

A time-based one-time password (TOTP) is a temporary passcode generated by an algorithm that uses the current time of day as one of its authentication factors.

Time-based one-time passwords are commonly used for two-factor authentication and have seen growing adoption by cloud application providers.

TOTP is in fact a further development of HOTP, which stands for HMAC-based one-time password. Like HOTP, TOTP is based on the HMAC procedure – the hash operation in the background. Both the user’s device and the server generate a hash value by combining the secret key with a counter. 

The two values are identical, which is how the authentication works.

The hash function itself is not defined; in practice SHA-1 is often used (including by Google Authenticator, for example). SHA-1 generates a 160-bit hash value. For convenience, this value is truncated using a compression function. 

The final result is a short number (six digits for example) which the user can easily use to sign in to the web service.

For the time-based one-time password algorithm, there are three important formulas:

TOTP = HOTP(SecretKey,CurrentTime)

This basic formula simply defines that the TOTP is a HOTP procedure with two parameters – SecretKey and CurrentTime:

SecretKey: Randomly generated password, known to both the server and the client

CurrentTime: Current time in Unix time

However, this time value changes every second, which doesn’t leave the user long enough to enter the generated code. 

In other words, one second later, the TOTP is no longer valid, because the server has already generated a new hash value. A further formula is therefore required:

CurrentTime = floor((unixtime(now) – unixtime(T0))/T1)

The CurrentTime parameter is defined as follows:

unixtime(now): Current time in Unix time

unixtime(T0): Unix time at T0, the point from which the time steps are counted – in most cases midnight on January 1, 1970 (=0)

T1: The period for which the TOTP will be valid (usually 30 seconds)

floor: Rounding function to round the calculated value down to a whole number

Multi-Tenancy in SpringBoot

 Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant.

Tenants may be given the ability to customize some parts of the application, such as the color of the user interface (UI) or business rules, but they cannot customize the application’s code.

We can implement multi-tenancy using any of the following approaches:

Database per Tenant: Each Tenant has its own database and is isolated from other tenants.

Shared Database, Shared Schema: All Tenants share a database and tables. 

Every table has a Column with the Tenant Identifier, that shows the owner of the row.

Shared Database, Separate Schema: All Tenants share a database, but have their own database schemas and tables.