Messaging System:

A messaging system lets you send messages between processes, applications and servers.

Why we need Kafka:

• We need an effective messaging system or platform which can capture the big data generating sources and try to analyze and present all the rightful information to the rightful sources at the right time.
• It has built-in partitioning, replication, and fault-tolerance that makes it a good solution for large-scale message processing applications.

Kafka Components:

Kafka has 5 components in the cluster.

1) Zookeeeper:- It is primarily used as a configuration or registry type of index. It is a independent Apache project which kafka recommends and incorporates for its internal use, It is open source project which is highly available system. Primarily used for coordination and lookup service as a registry index in a distributed system. Primarily produces use zookeeper to identify the lead broker, so most of the times the producers interact with zookeeper to identify there are one two brokers in their cluster been set. Most of the producers interact with the zookeeper to identify the lead node/broker in the cluster

2) Broker:- Broker is nothing but a node/server in the cluster in which owns the topic

3) Topic:- It maintains the messages or bunch of the messages. These topics can be partitioned and distributed in multiple machines

4) Producer:- Producers are the ones which processes and publishes the incoming message or the activity data to the broker or to the cluster

5) Consumer:- Consumers are the processes which subscribe to the topics and pull all the msgs or the items or the data from the topics

Kafka Broker:

A Kafka cluster consists of one or more servers (Kafka brokers), which are running Kafka. Producers are processes that publish data (push messages) into Kafka topics within the broker. A consumer of topics pulls messages off a Kafka topic.

Kafka Topic:

A Topic is a category/feed name to which messages are stored and published. Messages are byte arrays that can store any object in any format. As said before, all Kafka messages are organized into topics. If you wish to send a message you send it to a specific topic and if you wish to read a message you read it from a specific topic. Producer applications write data to topics and consumer applications read from topics. Messages published to the cluster will stay in the cluster until a configurable retention period has passed by. Kafka retains all messages for a set amount of time and therefore, consumers are responsible to track their location.

Kafka topic partition:

Kafka topics are divided into a number of partitions, which contains messages in an unchangeable sequence. Each message in a partition is assigned and identified by its unique offset. A topic can also have multiple partition logs like the click-topic has in the image. This allows for multiple consumers to read from a topic in parallel.

In Kafka, replication is implemented at the partition level. The redundant unit of a topic partition is called a replica. Each partition usually has one or more replicas meaning that partitions contain messages that are replicated over a few Kafka brokers in the cluster. As we can see in the pictures – the click-topic is replicated to Kafka node 2 and Kafka node 3.

Note: It’s possible for the producer to attach a key to the messages and tell which partition the message should go to. All messages with the same key will arrive at the same partition.

Partitions allow you to parallelize a topic by splitting the data in a particular topic across multiple brokers.

Every partition (replica) has one server acting as a leader and the rest of them as followers. The leader replica handles all read-write requests for the specific partition and the followers replicate the leader. If the leader server fails, one of the follower servers become the leader by default. When a producer publishes a message to a partition in a topic, it is forwarded to its leader. The leader appends the message to its commit log and increments its message offset. Kafka only exposes a message to a consumer after it has been committed and each piece of data that comes in will be stacked on the cluster.

Developers can now authenticate their users on an app-by-app basis for everything from mobile purchases to app sign-in screens and more with just the tap of a finger. There are only three requirements for a user to to be eligible.

1. The user’s device must have a fingerprint reader.
2. The user’s device must be running Android 6.0 Marshmallow (API 23) or greater.
3. The user must have registered fingerprints on the device (more on this later)

API Overview

This overview will familiarize you with the workflow for using Android 6.0 Fingerprint APIs.A few main points to keep in mind:

1. Android Marshmallow has introduced a new permissions model that requires the user to give you sensitive permissions at runtime. Therefore, take into account that the user might not grant your app permission for fingerprint scanning.
2. You can create a symmetric key or asymmetric key pair for data encryption.
3. Keep the UI user-friendly. Make sure that the UI indicates when the scanner is ready for the user. It is recommended to use Google’s standard fingerprint icon which is easily recognized by users.

Let’s get started..

1. Set up the SDK and permissions in the manifest
   First, set your targetSdkVersion to “23” and add the USE_FINGERPRINT permission in your manifest.
   To add the permission in the AndroidManifest.xml file.

   <uses-permission 
   android:name="android.permission.USE_FINGERPRINT" />

2. Request a permission at runtime Call requestPermissions() in your Activity’s onCreate():
   

   requestPermissions(newString[]{Manifest.permission.USE_FINGERPRINT},FINGERPRINT_PERMISSION_REQUEST_CODE);

3. Check that the lock screen has been set up
   To check if the user has set up their lock screen, get an instance of KeyguardManager.
   

   KeyguardManager keyguardManager = (KeyguardManager)
   getSystemService(KEYGUARD_SERVICE);

4. Check whether the hardware is present and functional
   The FingerprintManager class coordinates all access to the fingerprint hardware. Using FingerprintManager we can check for device support, attempt authentication, and handle any successful or failed authentication attempts appropriately. The first thing we’ll need when implementing fingerprint authentication is an instance of FingerprintManager . This is a system-level service, so we need to call Context’s getSystemService(String) method, in the Context.FINGERPRINT_SERVICE constant.

   FingerprintManager fingerprintManager = (FingerprintManager)context.getSystemService(Context.FINGERPRINT_SERVICE);

5. Now with the FingerprintManager instance, First we can call isHardwareDetected() to receive a boolean indicating if the device has a fingerprint reader. If this returns false we’ll need to authenticate our user some other way. If isHardwareDetected() returns true, we’ll next need to call hasEnrolledFingerprints() to verify that the user has registered at least one fingerprint on the device. Even if the device has the necessary hardware, we can’t authenticate a user’s fingerprint if we don’t have a registered one  to compare against.
   

   if (!fingerprintManager.isHardwareDetected()) { 
       // Device doesn't support fingerprint authentication     
   } else if (!fingerprintManager.hasEnrolledFingerprints()) { 
       // User hasn't enrolled any fingerprints to authenticate with 
   } else { 
       // Everything is ready for fingerprint authentication 
   }

Authenticating the Fingerprint

This is done by calling FingerprintManager’s authenticate(CryptoObject, CancellationSignal, int, AuthenticationCallback, Handler) method.

CryptoObject – it is the wrapper class for the crypto objects which supported by the FingerprintManger.

CancellationSignal – This gives us the ability to stop listening for fingerprints. In a typical implementation, this class’ cancel() method will be called in the onPause() lifecycle method. This ensures we aren’t listening for fingerprints while the application isn’t available.

int – This is intended for flags, but currently we should only pass in 0.

AuthenticationCallback – This is the listener for fingerprint events. It provides four methods:

1. onAuthenticationError(int, CharSequence)
   Called when a fatal error has occurred. This method provides the error code and error message as its parameters. You should implement this method to notify the user an error has occurred.
2. onAuthenticationHelp(int, CharSequence)
   Called when a non-fatal error has occurred. This method provides the error code and a help message you can display to the user.
3. onAuthenticationFailed()
   Called when a user attempts authentication but the fingerprint is not recognized. You should always notify the user that their authentication attempt failed.
4. onAuthenticationSucceeded(AuthenticationResult)
   Called when a user’s fingerprint is successfully recognized. The AuthenticationResult parameter includes the CryptoObject associated with the transaction.

Test Your Code

To support the new APIs, ADB can emulate fingerprint touch events. If you only have one device running, the command for this is:

adb -e emu finger touch [finger_id]

If you don’t have a device with a fingerprint reader, you can use this command with an emulator running API 23 or greater to register and use fingerprints. To enroll one or more fingerprints, go to Settings > Security and ensure you have a screen lock enabled. Once a screen lock is enabled, you can select Fingerprint from the Settings screen and choose “Add fingerprint”. When the screen with the fingerprint icon appears, execute the above adb command.

Advantages of Using Fingerprint API

1. Doesn’t matter how sick you are or unable to recollect things, your fingerprint still stays faultless as your identity and can never be misplaced.
2. Fast, Convenient and Reliable to use.
3. Unique fingerprints assure that it’s unlocked just by you.
4. With the help of Fingerprint authentication, online transactions become more convenient, hence your just a tap away from getting verified.
5. Substitute for passwords and pin codes.
6. Fast Lock/unlock devices screen and apps.
7. Identification for connection to the Internet of things.

Why Bootstrap?

Bootstrap offers you a tried and tested, cross-browser, easy to use code instead of spending hours in writing your own CSS.

What is Bootstrap?

• Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web
• Bootstrap makes front-end web development faster and easier. It’s made for all skill levels, devices of all resolutions, and projects of all sizes
• Bootstrap includes HTML and CSS based design templates for typography, forms, buttons, tables, navigation, modals, image carousels and many other, as well as optional JavaScript plugins
• Bootstrap easily and efficiently scales your websites and applications with the same code base, from phones to tablets to desktops

How to install Bootstrap?

• Install with Bower – $ bower install bootstrap
• Install with npm – $ npm install bootstrap@3

What is Responsive Web Design?

            Responsive web design is about creating websites which automatically adjust themselves to look good on all devices, from small phones to large desktops.

Pros:

• Easy to use: With just basic knowledge of HTML and CSS can start using Bootstrap
• Responsive features: Bootstrap’s responsive CSS adjusts to phones, tablets, and desktops
• Mobile-first approach: In Bootstrap, mobile-first styles are part of the core framework
• Browser compatibility: Bootstrap is compatible with all modern browsers (Chrome, Firefox, Internet Explorer, Safari, and Opera)
• It includes glyphicons, where there are hundreds of familiar icons like user, security, admin etc
• Good documentation and community support
• A lot of free & professional templates, themes and plugins are available

Cons:

• Websites can start to look the same if you don’t customize the styles and colors much
• It uses jQuery
• Layout grid will need over-riding if you want a fixed width column, like for advertising

The grid layout:

Sample  grid:

<!-- every row must have 12 columns --> 
<div class=”row”> 
   <div class=”col-md-4”> 
       <!-- content --> 
   </div> 
   <!-- need to complete 8 more columns --> 
</div>

Bootstrap 3 features an always-responsive grid with a maximum size:

1. col-xs-[num] grids have no maximum size (fluid)
2. col-sm-[num] grids resize up to 750px
3. col-md-[num] grids resize up to 970px
4. col-lg-[num] grids resize up to 1170px You should choose col-md or col-lg for desktop sites.

You should choose col-md or col-lg for desktop sites.

You can also use two grid sizes for different screen sizes:

<div class=”row”> 
    <div class=”col-md-4 col-xs-6”> 
        <!-- content --> 
    </div> 
    <div class=”col-md-8 col-xs-6”> 
        <!-- content --> 
    </div> 
</div>

The features like Responsive, Browser Compatibility, Default Icons & Grid layout made me use Bootstrap in most of my Apps.

The TouchID is a feature based on a new framework called Local Authentication, which provides facilities for requesting authentication from users with specified security policies.

Local Authentication handles everything in context of handling the Touch ID while using in our applications. It will prompt for authentication with custom message which will tell user why we need authentication, so user can place his finger on the home button.

Why we integrated the Touch ID with iOS Apps?

Touch ID helps to protect information in iPhone,iPad and MAcbook pro’s

Is Touch ID secure ?

Yes, Touch ID is secure. All fingerprint information is encrypted and stored in Apple’s new A7 chip. Touch ID doesn’t store any images of fingerprints,but it does store “mathematical representation” of fingerprints. Apple said it is not possible for a fingerprint image to be “reverse-engineered” from mathematical representation.

Things to remember: Only for foreground Applications

Implementing the TouchID Authentication:

First we will need to import the Local Authentication framework at the top of the ViewController.

The Local Authentication framework is quite small for Apple standards. It only has one class named LAContext.First we need to create an authentication context.  We do this by creating an instance of the LAContext class

Step1: Check if TouchID is available or enrolled on the iPhone.Because not every device has a TouchID sensor, we need to ask the context if there is a fingerprint sensor.

Step 2: Once we are sure that TouchID is available and enrolled by the user, its time to ask user to provide the Touch ID to proceed.

Provide localized reason string, It will help users to understand, why this application is asking for the TouchID.

If TouchID authenticatin is not available, the reason can be identified by accessing the errorCode property of the error parameter and will fall into one of the following categories:

• Error.touchID Not Enrolled – The user has not enrolled any fingerprints into TouchID on the device.
• LAError.passcodeNotSet – The user has not yet configured a passcode on the device.
• LAError.touchIDNotAvailable – The device does not have a TouchID fingerprint scanner.

Touch ID Work Flow:

App Creation:

Advantages:

The Touch ID fingerprint sensor on the phone makes it easier for users to unlock their phone without having to remember a long, complex password. Passwords are becoming less popular because they are easily guessed. The new feature on the iPhone allow users to use the sensor along with a password. Having multiple methods of authentication makes it harder for someone to hack a person’s phone. Also, the phone comes with Find My Phone and a Wipe application that allow users to get rid of their personal information if someone steals their phone.

Spock allows dynamic method names:-

def “maximum of #a and #b is #c”() {

expect:

dao.maxNum(a, b) == c
where:
a | b || c
1 | 7 || 7
8 | 4 || 8
9 | 9 || 9
}
After executing the above code using JUnit, we can see the method names as

Mocking in Spock Framework:

In the following example, we are mocking StudentDao class. We can mock a class in two ways
1. StudentDao studentDao = Mock()
2. def studentDao = Mock(StudentDao)

class StudentServiceSpec extends Specification{
StudentDao studentDao = Mock()
StudentService studentService = new StudentService(studentDao)
def “inserting Student Details”(){
setup:
studentDao.insertStudent(_ as Student) >> 1
studentDao.getLastRecordId() >> 70
when:
def response = studentService.insertStudent(new Student())
def se = (Student)response.getEntity()
then:
response != null
se.getStudentId() == 70
}
}

WireMock:
      WireMock is great at mocking out HTTP APIs when writing integration tests.

Integration Test using WireMock in Spock Framework:

@UseModules(value=[StudentMiddleModule])
class StudentRestServiceIT extends Specification {
@Rule
public WireMockRule server = new WireMockRule(wireMockConfig().port(9000))
@Inject
IStudentMiddleService studentMiddleService
static String PATH = ‘/vod/accountInfo’
def ‘validate Get Student by accountNumber ‘() {
given:
server.stubFor(get(urlPathEqualTo(PATH))
.willReturn(aResponse()
.withStatus(200)
.withBodyFile(‘response.xml’))
)
when:
StudentMiddleMessage studentMiddleMessage = studentMiddleService.getStudent(‘8087300010143918’)
then:
studentMiddleMessage != null
studentMiddleMessage.getStudentSet() != null
studentMiddleMessage.getStudentSet().getCredit() == ‘4779.37’
studentMiddleMessage.getStudentSet().getStudentItems() != null
studentMiddleMessage.getStudentSet().getStudentItems().size() == 1
}
}

Why did we chose Spock:

• Spock has built-in support for Mocking and Stubbing without an external library.
• One for the killer features of Spock is the detail it gives when a test fails. JUnit only mentions the expected and actual value, where Spock records the surrounding running environment mentioning the intermediate results and allowing the developer to pinpoint the problem with greater ease than JUnit.

Conclusion:-

In Spock, we don’t have tests, we have specifications. These are normal Groovy classes that extend the Specification class, which is actually a JUnit class. Our class contains a set of specifications, represented by methods with funny-method-names-in-quotes. The funny-method-names-in-quotes take advantage of some Groovy magic to let us express our requirements in a very readable form. And since these classes are derived from JUnit, we can run them from within Eclipse like a normal Groovy unit test.

Asynchronous programming is a means of parallel programming in which a unit of work runs separately from the main application thread and notifies the calling thread of its completion, failure or progress.

Why do we need Asynchronous programming?

The simple answer is we want to deliver a smooth user experience to our users without freezing the main thread and to make our application more responsive. To keep the main thread free we need to do a lot of heavy and time-consuming work in the background.

In asynchronous programming, thread management is the key.  While working with multiple threads, the other thread should experience minimum side effects from the other thread. That makes your code easily readable and understandable to a new person and it also makes error easily traceable. This is where reactive programming comes in.

What is Reactive Programming?

Reactive programming is asynchronous programming with observable streams. Observer pattern is used when there is one to many relationship between objects such as if one object is modified, its dependent objects are to be notified automatically and corresponding changes are done to all dependent objects.

Think Twitter. When you say you want to follow someone, Twitter adds you to their follower list. When they sent a new tweet, you see it in your input. Same idea, in that case, your Twitter account is the Observer and the person you’re following is the Observable.

RX = OBSERVABLE + OBSERVER + SCHEDULERS

We are going to discuss these points in detail one by one.

• Observable:  Observable are nothing but the data streams. Observable packs the data that can be passed around from one thread to another thread. There are various operators that can help observer to emit some specific data based on certain events.
• Observers: Observers consumes the data stream emitted by the observable. Observers subscribe to the observable using subscribeOn() method to receive the data emitted by the observable. Whenever the observable emits the data all the registered observer receives the data in onNext() callback. If there is an error thrown from observable, the observer will receive it in onError().
• Schedulers: Remember that Rx is for asynchronous programming and we need a thread management. There is where schedules come into the picture. Schedulers are the component in Rx that tells observable and observers, on which thread they should run.

Let’s look into the basic example.

Observable<String> observableString = Observable.just(new String[]{“1″,”2”,”3”); Observer<String> observer = new Observer<String>() {
@Override
public void onCompleted() {
System.out.println(“Completed!”);
}
@Override
public void onError(Throwable e) {
System.out.println(“Error!”);
}
@Override
public void onNext(String value) {
System.out.println(“onNext: ”+ value);
}
};

observableString.subscribeOn(Schedulers.newThread()) .observeOn(Schedulers.mainThread()
.subscribe(observer);

Output is:
onNext: 1
onNext: 2
onNext: 3
Complted!

Step-1 Create observable that emits the data:

Here observableString is an observable which emits the data. In our case, it emits the strings. just() is an operator.

Step -2 Create observer that consumes data:

In above code observer is an observer that consumes the data emitted by the observableString observable. It processes the data received and also handles error inside it.

Step-3 Manage concurrency:

At the last step, we define our schedulers that manage the concurrency. subscribeOn(Schedulers.newThread()) tells observableString observable to run on background thread. observeOn(Schedulers.mainThread()) tells observer to run on the main thread. This is basic code for reactive programming.

Conclusion:

To summarize, Reactive programming is the best choice to do asynchronous work with the streams of data. I hope this serves as a useful introduction to Reactive programming and an overview of its basic capabilities. It also has much more powerful concepts. To learn more about reactive extensions browse the resources available at ReactiveX.

• Asynchronous: Both parties either client or server can communicate with each other at the same time.
• WebSockets: Support two-way communication between server & client, both can send data at the same time
• Comet: Enables servers to send data to the client without having received a client request

Why Atmosphere?

Based on the requirement we need a framework which supports bi-directional communication so we have selected Atmosphere Framework. The requirement includes WebSockets. The main advantage of a WebSocket is that it provides two-way communication between client and server over a single TCP connection.

Generally, a web application works in a request and response pattern, client will send a request to server then server returns the response. For every request from the same client to same server, a new connection needs to be opened.

A websocket will maintain a single connection between the client and server. It also keeps the connection alive with all its clients until they disconnect.

Atmosphere supports both Server(JAVA, Scala&Groovy) and Client (Javascript)

Need for Web Sockets:

Before getting into why we need Web Sockets, it is necessary to have a look at existing techniques, which are used for duplex communication between the server and client

• Polling: This is a method which involves client making a periodic request at a specified time interval to the server. Then server includes data available or some message in response.
• Another technique is Streaming, for real-time data transmission. The server keeps the connection alive and active with the client until it fetches the data from server. It includes HTTP headers and increases file size, delay.
• Long Polling: This is similar like Polling, Client and Server keeps the connection active until data is fetched or even timeout occurs, Long Polling is nothing but performance improvement but constant request may slow down the process.

All the above techniques support duplex communication. A client is always required to send a request and a server can’t send message by itself, this problem can be resolved using Web Sockets

Web Socket: Web Socket is a protocol that provides full-duplex communication. The data can travel both sides simultaneously, as per the motto of this technique, like in a hand shake, anybody can start, in technical words either the client or server anybody can send a message first.

Eg. This example will give you a clear picture; assume there is an army with a chain of command. Here Server is General, and browsers are soldiers waiting for orders (responses), Using HTTP/REST every soldier has to ask the General if there are any new orders for him, it actually burdens the General who needs to give a response to all the soldiers separately.

In case of a Web Socket General will send a message whenever he wants to and it will reach all the soldiers at once

1. Server:

To Implement an Atmosphere application, we have used @MangedService annotation in the rest layer to create the Atmosphere Service. This is the simplest way to create Atmosphere service, if we use this annotation there is no need to interact with the core Atmosphere’s API’s.

@ManagedService:

We can simply implement Atmosphere from server side as shown above, it supports Annotations over class level and method level

@Singleton: The Singleton annotation is class level annotation, it can be used to force Atmosphere to create a single, thread safe instance of a @ManagedService annotated classes. If we use this annotation we can restrict atmosphere to create single object which is annotated to @ManageService class.

Following are the multiple class level annotations

• @Ready: It is called when the connection is fully established
• @Message: It will be invoked when a message is ready to deliver either request/response
• @Disconnect: It will be invoked when the client is closed the connection or a network outage
• @Resume: It will be invoked when the connection is resumed, this principally happens with the long-polling transport.
• @GET, @POST, @PUT To tell the framework to dispatch HTTP relevant annotated methods

Broadcaster:

A Broadcaster is responsible for delivering messages to its subscribed Atmosphere resources (clients), we can subscribe to one or more Broadcasters to get notified about events. By default single Broadcaster is created by Atmosphere and it is associated with all clients, the default Broadcaster’s Id is always “/*”, which means to invoke all clients.

We have another implemented class MetaBroadcaster, It’s really helpful when you want to broadcast messages to all or to specific users

Deliver message to all clients: metaBroadcaster.broadcastTo(“/”, “hello client”);

Deliver message to specific client(s): metaBroadcaster.broadcastTo(“/a/*”, “hello world”);

Conclusion: Atmosphere framework makes the development easier to build Asynchronous Web applications that include a mix of WebSocket, Comet and RESTful behaviour. The Atmosphere Framework is portable and can be deployed to any web server.

Ansible is a configuration management and provisioning tool that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

It works by establishing a connection between the nodes, through SSH, and pushing small programs called modules. In Ansible-speak, a script is called a playbook. A playbook usually contains a list of hosts (what Ansible calls remote servers) that need to be configured and an ordered list of tasks to perform on those hosts.

Why Ansible:

• Resource utilization: Ansible is an agent-less software and does not require any extra services or daemons to be installed on its nodes.
• Security: Ansible uses SSH connection protocol between Ansible server and its nodes. Using an SSH connection is more secure because the connection is encrypted.
• Idempotency: Ansible modules are idempotent which means that modules can be safely re-run any number of times.
• Simple Code: Ansible programs or modules are written in simple YAML script files and can be created either by placing everything in a single file or by following a structured model.

Below is the comparison chart for some of the configuration management tools available:

Use Ansible to configure 4Linux (ubuntu-based web servers to install nginx)

How Ansible works

For example, consider hosts as webserver 1, 2, 3, and 4.  Ansible uses inventory file (a list of nodes) to establish communication.

# /etc/ansible/hosts

[webservers]

webserver1.hostname.com

webserver2.hostmame.com

webserver3.hosname.com

webserver4.hostname.com

Below are the tasks we are going to perform:

• Install nginx
• Generate nginx configuration file
• Start the nginx service

Let us name the playbook, webserver.yml, and execute the below command.

Webserver.xml

---

- hosts: webservers

tasks:

- name: Installs nginx web server

apt: pkg=nginx state=installed update_cache=true

notify:

             - start nginx

# ansible-playbook webservers.yml

Once the above command is executed, Ansible makes ssh connection parallely with all the nodes and performs nginx web configuration tasks.

Ansible Execution Flow

 We found below challenges in our onsite-offshore model:

• Communication
• Accountability
• Measuring Progress
• Dependencies
• Built Trust & Confidence
• Meetings
• Trainings
• Documentations

Agile process helped us to overcome these challenges.

• Accountability
  • We use JIRA to assign tasks and it is each individual’s responsibility to complete the task
  • As part of the process, each user story is associated with QA task. On completion of the QA task, Jira ticket is closed
  • We make sure that each Developer/QA is assigned not more than 3 tickets at any given point. Developer will act on the task based on priority
  • We have one point of contact [lead] for each project from onsite and offshore to discuss on the below
    • Offshore team lead will give the status of the tasks and handover to onsite to work on remaining tasks and vice versa. It helps us in delivering things faster and effectively.
• Communication
  • We maintain constant communication with daily Scrums
    • Update the status of the task
    • Discuss about dependencies & prioritization of the tasks
    • Re-assign the tasks based on the priority
  • We use below communication channels to contact onsite teams
    • Skype
    • Webex
    • GoToMeeting
    • Hipchat
    • Whatsapp
    • Mails
  • We make  sure onsite  and offshore teams are included in all communications, meetings, or other relevant events
  • We use below communication channels for sharing information
    • Confluence
    • Drop box
• Measuring Progress
  • JIRA will give us status & progress of the tasks at any given time by creating boards [In Agile, scrum has ability to track progress at any given point]
  • We do maintain other metrics which explain in detail about the traceability matrix , defects and RCA
• Dependencies
  • We overcome the dependencies by
    • Identifying the areas where the onsite dependencies are zero and assign those tasks offshore
    • Increasing the overlapping time

• Built Trust & Confidence
  • Identifying the problem and use defined process to resolve
  • Keep expectations clear with onsite and discuss with them by using our regular communication channels
  • Deliver the tasks on time and identifying the dependencies early in dev stage and act accordingly
• Meetings
  • We use below communication channels for meetings
    • GoToMeeting
    • Webex
    • Skype
  • We send meeting invites with agenda to targeted audience so that it won’t be open-ended meetings
  • Most of the times we will keep result oriented meetings and MOM sent to the team
  • For each sprint, we do status meetings and retrospectives to improvise the process
• Trainings
  • Offshore trainings
    • Best practices
    • New technologies
    • Knowledge sharing on feature which each developer owning
  • Onsite trainings
    • Cross functional training
    • Feature training
    • KT on the feature they own
    • New technologies which we are going to use
  • Communication channels for trainings
    • Webex
    • Skype
    • Overseas travelling
    • Meeting Rooms

There are different PayPal products available for accepting online payment.  Few of them are listed below.

• PayPal Payments Standard
• Express Checkout
• Website Payments Pro
• Payflow Gateway
• Mobile Checkout
• Mass Payments
• Virtual Terminal
• IPN

Of the above, Paypal Payments Standard, Express Checkout and IPN are available for all countries. For one of our projects, we used Express Checkout.

Steps for implementing ‘Express Checkout’ payment method

1. Login to PayPal business account
2. Use sandbox for testing
3. Coding, debugging and testing the application
4. Going live

Login to PayPal business account

To accept payment, the service provider should have a business account.

Use Sandbox for PayPal testing

Sandbox is a free-to-use service. In our project, we created one business account and few personal accounts for testing. We created these accounts by visiting https://www.sandbox.paypal.com. To simulate PayPal checkout flow, we added money to these accounts and did some transactions.

Coding, debugging and testing the application

PayPal Express Checkout

Express Checkout allows merchants and developers to minimize the number of steps a customer should complete to checkout. Customers can checkout without leaving the merchant’s site via PayPal in-context checkout window overlaying the merchant’s website or pay on PayPal’s secure site and return to the merchant’s website to complete the transaction. We used in-context checkout method in our project.

Checkout Flow

When the customer clicks on ‘pay with PayPal’ button, the merchant’s website makes an API call to PayPal to pass the transaction details. Customer is redirected to an in-context PayPal checkout window to login. After logging in, the customer selects a shipping address and payment method. Note: In our project, shipping address was not required, so we omitted that.

PayPal then redirects the customer to the merchant’s website to review and approve the order details. The merchant’s website then makes an API call to retrieve transaction details, email address, and other information needed to fulfill the order. Customer then reviews and approves the payment. When customer completes the order, the website makes an API call (unseen by the customer) to PayPal to request payment. After successful transaction, an email is sent to the customer providing transaction details. If customer doesn’t want to approve the payment, he clicks on ‘cancel and return to merchant’s website link.’ Note: For fraud detection, we have used sift science in our project.

NVP/SOAP API SDKs

For integration, i.e., for processing and accepting PayPal’s payment, we used PayPal SDK instead of creating messages as NVP strings or SOAP structures. These SDKs enabled us to code in our preferred programming language. We used NVP/SOAP API SDK in java, viz., Merchant Java SDK. While testing with sandbox, we used sandbox api credentials. For doing real transactions, we replaced api keys with those from our live paypal account.

PayPal Authorization Flow

• Authorization
• Capture payment
• Void authorization

In our project, we processed the customer’s request after accepting the payment from them through PayPal. First, we did payment authorization, i.e., customer’s amount will be put on hold by PayPal. After authorization, we processed the customer’s request. If customer’s request was processed successfully, we captured the payment, else we voided the authorization, i.e., removed ‘hold.’

Accepting credit card/debit card payment with PayPal

If the customer does not have a PayPal account, payment can be done using a credit/debit card. However, we can’t modify the default UI screen and we can’t write our own form validations, etc. To do so, we have to develop credit/debit card functionality separately.

We can use rest-api-sdk to process credit/debit card, create tokens, accept payment, etc. Here, we can customize credit/debit card processing form. We can write form validation, enhance look and feel of buttons and input text boxes, etc. To save the card used by the customer for future purchases, we don’t have to save card numbers and details, but we just have to save the card tokens which we created with the help of rest api.

Maven dependency for rest api sdk is as below.

</dependency>
<groupId>com.PayPal.sdk</groupId>
<artifactId>rest-api-sdk</artifactId>
<version>1.4.1</version>
</dependency>

Debit/credit card form in express checkout will look as shown below.

Payment flow Diagram

Note: Sift refers to Sift Science, a fraud detection solution for websites, which will not be discussed in detail here.

Going live

Once we finish coding, debugging and testing our application, we can move our application to PayPal’s production environment.

While moving the application live:

• Replace the Sandbox API credentials with live PayPal account’s credentials.
• Update PayPal endpoints from the Sandbox to the PayPal production servers.
• Replace the sandbox mode with live mode in configuration.
• Register application with PayPal.

Steps for registering the application to PayPal.

1. Go to https://developer.PayPal.com/ log in using PayPal business account.
2. Click Dashboard at the top of the page to open the My Apps & Credentials.
3. Click the Create and manage NVP/SOAP API apps. link at the bottom of the page.
4. Click on Login with PayPal.
5. Login with your primary username and password.
6. Click on New Application.

After clicking on New Application, we will get below form which has to be filled out and submitted.

Ref: https://developer.PayPal.com/