Pralesha slideshare

INTEGRATION WITH CLOUD BASED SALESFORCE.COM’s FORCE.COM PLATFORM
AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-161
“INTEGRATION WITH CLOUD BASED
SALESFORCE.COM’s FORCE.COM PLATFORM”
SubmittedBy
MS. PRALESHA P. JADHAV (B120258536)
Guided By
Prof. PRITESH A. PATIL
Bachelor of Engineering in Information Technology
SAVITRIBAI PHULE PUNE UNIVERSITY
ALL INDIA SHRI SHIVAJI MEMORIAL SOCIETY’S
INSTITUTE OF INFORMATION TECHNOLOGY, PUNE
ACADEMIC YEAR 2015-2016

Sponsorship Letter

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16I
INDEX
Table of Contents
ABSTRACT..................................................................................................................IV
List of Tables: ................................................................................................................V
List of Figures:..............................................................................................................VI
List of Graphs: ........................................................................................................... VIII
List of Abbreviations: ...................................................................................................IX
0.1 Project Title..............................................................................................................X
0.2 Internal Guide ..........................................................................................................X
0.3 Sponsorship and External Guide..............................................................................X
0.4 Problem Statement ..............................................................................................X
CHAPTER 1 ...................................................................................................................1
INTRODUCTION ..........................................................................................................1
1.1 Information about the system...........................................................................2
 Motivation: ...................................................................................................2
 Aim/Goal: .....................................................................................................2
 Objectives: ....................................................................................................3
 Project Scope: ...............................................................................................3
1.2 Overview of the target for the final system:.....................................................6
1.3 Overview of the technical area:........................................................................7
Security Integration.................................................................................................7
User Interface Integration .......................................................................................7
Business Logic Integration......................................................................................7
Data Integration.......................................................................................................7
1.4 Summary of the system functionality: .............................................................7
Chapter 2.........................................................................................................................9
NEED FOR INTEGRATION OF SALESFORCE WITH EXTERNAL SYSTEM
HEROKU........................................................................................................................9
2.1 CLOUD INTEGRTION PROVIDES FOLLOWING FEATURES:.............10
 Security: .........................................................................................................10
 Flexibility: ......................................................................................................11
 Management:..................................................................................................11
 Open Platform: ...............................................................................................11
2.2 NEED OF SALESFORCE FOR INTERGRATION .....................................11

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16II
CHAPTER 3 .................................................................................................................13
BACKGROUND AND LITERATURE SURVEY ......................................................13
3.1 Force.com is the fastest way to create enterprise cloud apps .........................14
3.2 Heroku lets you develop amazing customer apps that sync with Salesforce.15
3.3 Enterprise WSDL ...........................................................................................15
Chapter 4.......................................................................................................................17
REQUIREMENTS AND ANALYSIS .........................................................................17
4.1 Problem Statement: ........................................................................................18
4.2 Specifications of the System ..........................................................................18
4.2.1 Functionality provided by the system:....................................................18
4.3 System interfaces, inputs, and outputs ...........................................................19
 User Interfaces:...........................................................................................19
 Software Interfaces:....................................................................................19
 Communications Interfaces: .......................................................................19
4.4 Expected Outcomes........................................................................................19
4.5 System Requirement ......................................................................................20
i. Performance Requirements ............................................................................20
ii. Hardware Requirement...............................................................................20
iii. Software requirement..................................................................................20
iv. Security Requirements................................................................................20
4.6 Requirement Analysis:...................................................................................21
Chapter 5.......................................................................................................................25
Software Design............................................................................................................25
5.1 System Architecture Diagram........................................................................26
5.1.1 Modules in the project.............................................................................27
5.2 Diagrams ........................................................................................................31
i. Entity relationship diagram............................................................................31
ii. Data Flow Diagram.....................................................................................32
iii. UML diagram .............................................................................................32
5.3 Mathematical Concept Used: .........................................................................38
5.4 Feasibility Study.............................................................................................39
5.5 Software Development Life Cycle Phase.......................................................40
Chapter 6.......................................................................................................................44
Implementation .............................................................................................................44
6.1 Working of Proposed System: .........................................................................45
6.2 Implementation .................................................................................................46

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16III
Chapter 7.......................................................................................................................54
RESULT ANALYSIS...................................................................................................54
7.1 Testing:.............................................................................................................55
Chapter 8.......................................................................................................................59
CONCLUSION.............................................................................................................59
Chapter 9.......................................................................................................................61
PROJECT MANAGEMENT........................................................................................61
9.1 Project Plan: ...................................................................................................62
9.2 PERT Chart.......................................................................................................63
Chapter 10.....................................................................................................................64
References.....................................................................................................................64

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16IV
ABSTRACT
The System developed in Cloud should integrate with other systems and allow
seamless integration for information exchange between systems. Salesforce.com’s
Force.com platform provides a number of integration points ranging from off-the-shelf
native ERP connectors to web services, email, syndication feeds and HTTP-based
REST callouts. The platform also supports several APIs, including the Force.com
SOAP and REST APIs, providing the basis for integration with other languages such
as Java, .NET, ruby, objective-C and PHP. The proposed system is about integration
of Force.com cloud based system with external system. The system uses Force.com
SOAP or REST APIs. In order to integrate with any external system and seamlessly
fetch and process data. They provide direct access to data within Salesforce.com
Instance using these APIs, the proposed system creates a client that integrates with
Force.com from your language of choice. Heroku is used as a powerful Platform as a
Service (PaaS) for deploying applications in a multitude of languages, including Java.
Web application using the external framework with MVC framework to handle request
– response application in Salesforce.com cloud based system. Web service callout is
the mode of integration of the Salesforce.com Wen App with the External System.
This fulfilment system can be written in any other language like Java, .Net etc. and
hosted on Heroku, or it could be any application with a Web service interface.

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16V
List of Tables:
Table no. Name of the Table Page no.
Table 4.6.1 Requirement Analysis…………………………........................ 21
Table 7.1 Test cases…………………………………............................... 54
Table 9.1.1
High level project plan (project deliverables and
timelines)……………………………………………………....
61

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16VI
List of Figures:
Figure no. Figure Name Page no.
Figure. 5.1.1 System Architecture…………………………………….. 6
Figure 5.2.1 Entity relationship diagram…………………………... 31
Figure. 5.2.2 Data Flow Diagram………………………………….. 32
Figure. 5.2.3 Use Case Diagram……………………………………..... 32
Figure 5.2.4 Class Diagram…………………………………………... 33
Figure 5.2.5 Package Diagram……………………………………….. 33
Figure 5.2.6 Sequence Diagram…………………………………. 34
Figure 5.2.7 Communication Diagram…………………………... 34
Figure 5.2.8 Activity Diagram…………………………………... 35
Figure 5.2.9 State Machine Diagram……………………………. 36
Figure 5.2.10 Component Diagram……………………………….. 37
Figure 5.2.11 Deployment Diagram………………………………. 37
Figure 5.3.1 Salesforce Platform Landscape…………………….. 38
Figure 5.5.1 Software Development Life Cycle………………… 40
Fig. 3.5.2 SDLC of Salesforce………………………………... 42
Figure. 5.1.1 Working of Proposed System…………………………… 45
Figure 6.2.1 Salesforce login…………………………………………. 46
Figure 6.2.2(a) App Creation…………………………………………..... 46
Figure 6.2.2(b) App Creation…………………………………………..... 47
Figure 6.2.2(c) App Creation…………………………………………..... 47
Figure 6.2.2(d) App Creation…………………………………………..... 47
Figure 6.2.3 App Home Page……………………………………….... 48
Figure 6.2.4(a) Adding Merchandise……………………………….. 48
Figure 6.2.4(b) Adding Merchandise……………………………….. 49
Figure 6.2.5(a) Creating Invoice……………………………………. 49
Figure 6.2.5(a) Creating Invoice……………………………………. 50

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16VII
Figure 6.2.6(a) Integration with Heroku……………………………. 50
Figure 6.2.6(a) Integration with Heroku……………………………. 51
Figure 6.2.7(a) Heroku dashboard………………………………….. 52
Figure 6.2.7(b) Heroku dashboard………………………………….. 52
Figure 9.2.1 PERT Chart………………………………………… 62

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16VIII
List of Graphs:
Graph no. Name Of Graph Page No.
Graph 6.2.1 Cloud Based Integration (CBI) Dashboards…............... 51

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16IX
List of Abbreviations:
1. SFDC: Salesforce.com.
2. API: Application Program Interface.
3. SOAP: Simple Object Access Protocol.
4. REST: Representation State Transfer.
5. CBI: Cloud Based Integration

AISSMS INSTITUTEOF INFORMATION TECHNOLOGY-INFORMATIONTECHNOLOGY-2015-16X
0.1 Project Title
Integration with Cloud Based Salesforce.com’s Force.com Platform.
0.2 Internal Guide
Prof. Pritesh A. Patil
0.3 Sponsorship andExternal Guide
YES
0.4Problem Statement
Integration with cloud based Salesforce.com’s force.com platform with External
System - Heroku using REST API.

CHAPTER 1
INTRODUCTION

CHAPTER 1
INTRODUCTION
This chapter gives an overview of “INTEGRATION WITH CLOUD BASED
SALESFORCE.COM’s FORCE.COM PLATFORM”
1.1 Information aboutthesystem
A typical enterprise uses many applications, many or most of which are not
designed to work with one another out of the box. Integrating separate but related
apps helps organizations achieve greater levels of operational consistency,
efficiency, and quality. Each application can have data, business logic,
presentation, and security layers, all of which are possible targets for integration.
This project is an overall launch point for exploring the various integration
options related to Force.com and other Salesforce platform technologies. The
Software developed in Cloud should integrate with other systems and allow
Seamless integration for information exchange between systems. If it does not
allow integration with the External System, it does not allow real time data
exchange between systems for real time transactions. The standalone system need
to Import data manually, the system is not secured, Data may be loss or corrupt,
No real time transaction and it is not adoptable standard in Industry.
 Motivation:
A typical enterprise uses many applications, many or most of which are not designed
to work with one another out of the box. Integrating separate but related apps helps
organizations achieve greater levels of operational consistency, efficiency, and quality.
Each application can have data, business logic, presentation, and security layers, all of
which are possible targets for integration. This page is an overall launch point for
exploring the various integration options related to Force.com and other Salesforce
platform technologies.
 Aim/Goal:

To create an Application on Force.com platform for Real Time Integration with
External System with validation for user input that provides Application Security,
Data Security,Reports and Dashboards, Mobile Application for Analytics, Profile and
Role based security constraints,with the use of REST API for Integration with External
System
 Objectives:
 To establish real time integration between Salesforce.com and Heroku.
 To use suitable inbuilt features of force.com platform for application
development.
 To validate the proposed system along with Data Import, Data Export, Backup
and Restore.
 To test and implement the proposed system on Salesforce.com live cloud.
 Project Scope:
Integration with cloud based Salesforce.com’s Force.com platform will be used to
integrate two different applications on two different platforms.
Scope Includes:
 Cloud based Integration with External System:
Connect and access data from external sources with point-and-click simplicity.
Incorporate data from legacy systems in real time in Salesforce application
objects. Dramatically reduce integration time to unlock and modernize back
office systems.
 Page Layout and Record Types:
The organization of fields, custom links, and related lists on an object detail or
edit page.
Used to organize UI pages for your users:

– Which fields, related lists, and Custom links a user’s sees.
– Field properties – visible, read-only and required.
– Page section customizations.
 Security and Sharing:
Salesforce provides a flexible, layered data sharing design that allows you to
expose different data sets to different sets of users, so users can do their job
without seeing data they don't need to see. Use permission sets and profiles to
specify the objects and fields users can access. Use organization-wide sharing
settings, user roles, sharing rules to specify the individual records that users can
view and edit.
 User Access Control:
It is a technology and security infrastructure introduced
with Microsoft's Windows Vista andWindows Server 2008 operating systems,
with a more relaxed version also present in Windows 7, Windows Server 2008
R2, Windows 8, Windows Server 2012 and Windows 10. It aims to improve
the security of Microsoft Windows by limitingapplication software to
standard user privileges until an administrator authorizes an increase or
elevation. In this way, only applications trusted by the user may receive
administrative privileges, and malware should be kept from compromising the
operating system. In other words, a user account may have administrator
privileges assigned to it, but applications that the user runs do not inherit those
privileges unless they are approved beforehand or the user explicitly authorizes
it.
 Validation:
Improve the quality of your data using validation rules. Validation rules verify
that the data a user enters in a record meets the standards you specify before the
user can save the record. A validation rule can contain a formula or expression
that evaluates the data in one or more fields and returns a value of “True” or

“False”. Validation rules also include an error message to display to the user
when the rule returns a value of “True” due to an invalid value.
 Business Automation:
Business process automation (BPA), is the strategy a business uses to automate
processes in order to contain costs. It consists of integrating applications,
restructuring labor resources and using software applications throughout the
organization.
 Reports:
A report is a list of records that meet the criteria you define. It’s
displayed in Salesforce in rows and columns, and can be filtered, grouped, or
displayed in a graphical chart.
Every report is stored in a folder. Folders can be public, hidden, or shared, and
can be set to read-only or read/write. You control who has access to the contents
of the folder based on roles, permissions, public groups, and license types. You
can make a folder available to your entire organization, or make it private so that
only the owner has access.
 Dashboards:
A dashboard is a visual display of key metrics and trends for records in your
org. The relationship between a dashboard component and report is 1:1; for each
dashboard component, there is a single underlying report. However, you can use
the same report in multiple dashboard components on a single dashboard (e.g.,
use the same report in both a bar chart and pie chart). Multiple dashboard
components can be shown together on a single dashboard page layout, creating a
powerful visual display and a way to consume multiple reports that often have a
common theme, like sales performance, customer support, etc.
Like reports, dashboards are stored in folders, which control who has access. If
you have access to a folder, you can view its dashboards. However, to view the
dashboard components, you need access to the underlying reports as well. You
can also follow a dashboard in Chatter to get updates about the dashboard posted
to your feed.

Each dashboard has a running user, whose security settings determine which
data to display in a dashboard. If the running user is a specific user, all
dashboard viewers see data based on the security settings of that user—
regardless of their own personal security settings. For this reason, you’ll want to
choose the running user wisely, so as not to open up too much visibility. For
example, set the Sales Manager as the running user for a leaderboard for her
team. This allows her team members to view the leaderboard for their individual
team, but not other teams.
Dynamic dashboards are dashboards for which the running user is always the
logged-in user. This way, each user sees the dashboard according to his or her
own access level. If you’re concerned about too much access, dynamic
dashboards might be the way to go.
 Email Notifications on Order Closure:
Email notification is a feature of the MediaWiki software on
which Wikipedia runs. It allows editors who have registered an
account and provided an email address to receive automatic email notifications
when their user talk page or other watch listed page is changed.
The feature is activated on the English-language version of Wikipedia and can
be set in the Email options part of the User Profile section of your user
preferences.The template {{Email user notification}} signals that you have
email notification enabled. It produces the icon at the top right of this page.
1.2 Overview of the target for the final system:
In an enterprise uses many applications, many or most of which are not
designed to work with one another out of the box. Integrating separate but related apps
helps organizations achieve greater levels of operational consistency, efficiency, and
quality. Each application can have data, business logic, presentation, and security
layers, all of which are possible targets for integration. This project is an overall
launch point for exploring the various integration options related to Force.com and
other Salesforce platform technologies. The Software developed in Cloud should

integrate with other systems and allow Seamless integration for information exchange
between systems. If it does not allow integration with the External System, it does not
allow real time data exchange between systems for real time transactions. The
standalone system need to Import data manually, the system is not secured, Data may
be loss or corrupt, No real time transaction and it is not adoptable standard in Industry.
1.3 Overviewof thetechnicalarea:
Security Integration
Integrate authentication mechanisms across applications to improve the user
experience and minimize user administration.
User Interface Integration
Combine the UIs of two or more apps to create composite apps with little or no
rework on the UI of each individual app.
Business Logic Integration
Business logic often spans multiple application systems. Extending related
business logic from one app to another helps to implement complete end to end
business processes.
Data Integration
Integrating applications at the data layer is a common scenario. For example,
multiple apps written in different programming languages can all use an open API and
manage related data in one shared database.
1.4 Summaryof thesystem functionality:
There are a number of integration points on the Force.com platform. From a
developer perspective, you can get your hands dirty and invoke web services from the
platform, or expose classes on the platform as web service end-points. You can also
interact with external HTTP end-points, react to incoming email messages, and have
automated outbound messages sent when certain events occur.
With a slightly higher degree of sophistication, you can use the Force.com
SOAP and REST APIs. They provide direct access to data within your organization.

Using these APIs, you can create a client that integrates with Force.com from your
language of choice. A targeted REST API is also available for accessing Chatter data.
Toolkits that wrap around this API provide utility classes that make this
integration even easier for a range of languages, including Java, .NET, PHP, Objective
C, Ruby and Adobe Flex.
Salesforce.com provides a number of integration points ranging from off-the-
shelf native ERP connectors to web services, email, syndication feeds and HTTP-
based REST callouts. The platform also supports several APIs, including the
Force.com SOAP and REST APIs, providing the basis for integration with other
languages such as Java, .NET, Ruby, Objective-C and PHP.
This article provides an overview of the fundamental developer integration
points available on the Force.com platform. After reading this article you will be
aware of approaches you could take, and have enough pointers to more in-depth
material to implement your integration.

Chapter 2
NEED FOR INTEGRATION OF SALESFORCE WITH EXTERNAL
SYSTEM HEROKU

Chapter 2
NEED FOR INTEGRATION OF SALESFORCE WITH EXTERNAL
SYSTEM HEROKU
Cloud integration is necessary as it offers the following advantages over older,
compartmentalized organizational methods.
 Each user can access personal data in real time from any device.
 Each user can access personal data from any location with Internet access.
 Each user can integrate personal data such as calendars and contact lists served
by diverse application programs.
 Each user can employ the same logon information (username and password)
for all personal applications.
 The system efficiently passes control messages among application programs.
 By avoiding the use of data silos, data integrity is maintained and data conflicts
(which can arise from redundancy) are avoided.
 Cloud integration offers scalability to allow for future expansion in terms of
the number of users, the number of applications, or both.
In recent years, cloud integration has gained favor among organizations, corporations,
and government agencies that implement SaaS (Software as a Service), a software
distribution model in which applications are hosted by a vendor or service provider
and made available to users over the Internet.
2.1 CLOUDINTEGRTIONPROVIDESFOLLOWING FEATURES:
 Security: remains a concern for cloud users and is complicated by the
challenge of integration. A cloud integration solution must be capable of
authenticating and authorizing access to resources, both in the cloud and on-
premises. Moreover, it needs to be able to encrypt and store data (particularly
in a multitenant environment) and comply to different regulations such as
SSAE 16. With the growing number of SaaS applications, mobile apps and
social media services that need to access enterprise data, there needs to be a

secure means of connecting the cloud to the enterprise without compromising
the firewall.
 Flexibility: Point to point integration solutions can provide basic SaaS to SaaS
connectivity, but they are not sophisticated or flexible enough to handle more
complex scenarios. Cloud integration solutions must be able to support a
variety of integration flows moving in both directions across the cloud and
enterprise and scale up as the number of endpoints increases.
 Management: For enterprise users, SaaS applications offer convenience and
ease of use while shifting the burden of maintenance and upgrades to the
provider. The trade-off, however, is that users have much less visibility and
control over their SaaS applications, especially when it comes to integration.
Cloud integration solutions should include rich monitoring capabilities in order
to provide the visibility and control over information flows and other
performance attributes currently lacking in SaaS applications.
 Open Platform: Some SaaS vendors have started to offer out of the box
connectors to address the integration challenges of deploying a cloud strategy.
Unfortunately, as many system administrators who tackled integration
challenges during the pre-cloud era are likely aware, using an integration
solution from an application vendor limits the ability of enterprises to freely
choose and manage the IT solutions that best fit their needs. Ideally, cloud
integration solutions should be open platforms that allow enterprises to easily
migrate on or off and seamlessly integrate their applications and data.
2.2 NEED OF SALESFORCEFORINTERGRATION
quality.
Each application can have data, business logic, presentation, and security layers, all of
which are possible targets for integration. This page is an overall launch point for
exploring the various integration options related to Force.com and other Salesforce

Force.com provides a number of integration points ranging from off-the-shelf native
ERP connectors to web services, email, syndication feeds and HTTP-based REST
callouts. The platform also supports several APIs, including the Force.com SOAP and
REST APIs, providing the basis for integration with other languages such as Java,
.NET, Ruby, Objective-C and PHP.

CHAPTER 3
BACKGROUND AND LITERATURE SURVEY

CHAPTER 3
BACKGROUND AND LITERATURE SURVEY
3.1Force.comis the fastestwayto create enterprisecloud
apps[1][2][4][5][6]:
Force.com, the #1 Platform-as-a-Service, helps developers create and deploy
next-generation cloud apps, using rock-solid APIs and frameworks. Force.com
delivers an on-demand cloud database with easy tools for building data driven
applications and APIs for integrating with other apps.
API: Use REST and SOAP APIs to access, modify and report on your organization’s
data and to create notifications when it changes.
Mobile SDK: Everything you need to build custom native iOS and Android Apps.
Programmatic: Add business logic and triggers to your organization’s data with Apex
and build custom interfaces with Visualforce.
Drag & Drop Business Logic: Create and modify application components, including
objects, page layouts, reports, workflow rules, approval processes triggers, and more.
Social: Users, data, and processes are instantly social and feed first. Create custom,
contextually aware feed publishers to make your apps smarter and faster.
Security: Control access to your apps, data and logic with fine-grained programmatic
and user-level access control.
Here’s an example: the RestResponse object is included to illustrate where it would be
added to the method definition.

3.2Heroku letsyou develop amazing customer appsthatsync with
Salesforce[3][2]:
Heroku includes:
Heroku Connect: Bi-directional data sync between Heroku Postgres and Salesforce
so you can build apps that leverage your core customer data.
Languages You Love: Build Ruby, Node.js, Python, PHP, Java, Scala and Clojure
apps, and integrate them with your Salesforce apps using supported open source API
client libraries.
Add-on Marketplace: Dozens of fully managed cloud services you can add and scale
in a single command.
Instant, On-Demand Scale: Scale up quickly and reliably to meet traffic spikes,
accommodate more users, and deliver new features.
3.3EnterpriseWSDL[1][2][7][8]:
Salesforce provides two WSDL files, what are the differences?
Salesforce provides a WSDL (Web Service Description Language) files. They are
called "Enterprise WSDL" and "Partner WSDL". A WSDL is an XML-document
which contains a standardized description on how to communicate using a web service
(the Salesforce API is exposed as a web service). The WSDL is used by developers
to aid in the creation of Salesforce integration pieces. A typical process involves using
the Development Environment (e.g., Eclipse for Java, or Visual Studio for .Net) to
consume the WSDL, and generate classes which are then referenced in the integration.
The primary differences between the two WSDL that we provide are:
Enterprise WSDL:
a) The Enterprise WSDL is strongly typed.
b) The Enterprise WSDL is tied (bound) to a specific configuration of Salesforce
(ie. a specific organization's Salesforce configuration).

c) The Enterprise WSDL changes if modifications (e.g custom fields or custom
objects) are made to an organization's Salesforce configuration.
For the reasons outlined above, the Enterprise WSDL is intended primarily for
Customers.
Partner WSDL:
a) The Partner WSDL is loosely typed.
b) The Partner WSDL can be used to reflect against/interrogate any configuration
of Salesforce (ie. any organization's Salesforce configuration).
The Partner WSDL is static, and hence does not change if modifications are made to
an organization's Salesforce configuration.

Chapter 4
REQUIREMENTS AND ANALYSIS

Chapter 4
REQUIREMENTS AND ANALYSIS
4.1 ProblemStatement:
Real-time integration with cloud based Salesforce.com’s force.com platformwith
External System -“Heroku” using REST API.
4.2 Specificationsof theSystem
4.2.1 Functionality provided by the system:
 End user should go online and login into the Salesforce.com System(server)
 User should see salesforce.com Cloud based Integration home page with all
required tabs
 Create App to distinguish separate functionality and add logo to provide
branding to the application.
 User should be able to add Merchandise, set price and quantity, add Invoice,
with Status and Order ID for integration.
 Only authorized User should be able to delete Merchandise ,Invoice, and Line
Item
 Merchandise, Invoice and Line Item should have multiple page layouts.
 User can order items greater than zero and less than or equal to availability of
merchandise in stock.
 When user adds Invoice line items, Available merchandise should be
automatically reduced and updated quantity should be displayed on
merchandise.
 All line Items in Invoice should be rolled up to invoice total.
 Users/agents as well as managers should see dashboard i.e. graphical
representation of report on Salesforce UI and mobile device. Assign cases to
queue automatically and notify user/ agent by email using Salesforce
automation.

 System should allow Import, Export, Update, and Export All Data, Data
backup and recovery requirement, Schedule Reports and Email them to
specified users, Data migration from Legacy systems.
4.3 Systeminterfaces, inputs, and outputs
 User Interfaces:
The system uses the default User Interface provided by force.com platform, Salesforce
1 platform and the Visualforce page.
 Software Interfaces:
The software interface is based on the salesforce.com’s default interface.
 Communications Interfaces:
The Salesforce based application integrates and communicates with the external
system called Heroku via “Lighting Connector” - an interface for integration and
communication.
4.4 Expected Outcomes
 Theapplication created in Salesforce consists of various objects, fields,
relationships (Lookup and Master-Detailed relationship [MOR]) that provide
security to metadata and supports the validation given in the programming
aspects.
 Migration of data and code, replica of production, testing, deployment, UAT,
SIT, sandbox testing etc. is to be done.
 Salesforce based application integrate with an external system based on a
different platform called Heroku. Heroku provides an order id to the
merchandise that are added as line items in the invoice in on the Salesforce
platform and both the systems are updated simultaneously under a secure
functionality.

 Dashboards and reports of all the operations carried out are obtained in the
Salesforce based internal/base system.
4.5 SystemRequirement
i. Performance Requirements
 High Speed Internet (Broadband)
ii. Hardware Requirement
 2-4 GB RAM
 i3, i5, i7, AMD, Mobile Processors
iii. Software requirement
 Windows7/8.1/10 / Linux/Android/IOS
 Mozilla Firefox, IE 11, Chrome, Bing and any other browser.
 Apex Data loader
iv. Security Requirements
Securing access to your applications, data and logic is a key part of application
development and system configuration. This security should not only protect data and
logic from unauthorized external access, but also from unauthorized internal access—
for example by only granting data access to users with the appropriate authorization.
Force.com is built around a robust and flexible security architecture, providing you
with a fine degree of control over the users, network, and data. This article discusses
these various aspects of security—introducing everything from user and client
authentication through administrative permissions and the data access and sharing
model.
 Users and Security
 User Authentication
 Network-based Security
 Session Security
 Auditing
 Security Tokens

 Data Security
 Data Access
 Report and Dashboard Access
4.6 RequirementAnalysis:
Req# Requirement in Detail Priority Type
(F/N)
Signed
Off
Remark
CI001 End user should go online
and login into the
Salesforce.com
System(server)
High Functional Yes
CI002 User should see
salesforce.com Cloud based
Integration home page with
all required tabs.
High Functional Yes
CI003 Create App to distinguish
separate functionality and
add logo to provide branding
to the application.
High Functional Yes
CI004 User should be able to add
Merchandise, set price and
quantity.
High Functional Yes
CI005 User should be able to add
Invoice, with Status and
Order ID for integration.
High Functional Yes
CI006 Only Authorised User should
be able to delete
Merchandise ,Invoice, and
Line Item
High Functional Yes
CI007 Merchandise , Invoice and
Line Item should have
High Functional Yes

multiple page layouts
CI008 User can order items greater
than zero and less than or
equal to availability of
merchandise in stock.
CI009 When user adds Invoice line
items, Available merchandise
should be automatically
reduced and updated quantity
should be displayed on
merchandise.
High Functional Yes
CI010 All line Items in Invoice
should be rolled up to invoice
total.
High Functional Yes
CI011 User should be able to create
report on Merchandise and
create charts.
High Functional-
Report
Yes
report on Invoice and create
charts.
High Functional-
Report
Yes
report on Invoice Line Items
and create charts.
High Functional-
Report
Yes
CI014 User Should be able to see
Dashboard with 360 degree
view of real time data for
Merchandise, Invoice,
Invoice Line items and other
data sources.
High Functional-
Report –
Dashboard
Yes
CI015 Integrate with Heroku, Once
Order closed in Salesforce,
get order ID.
High Functional –
Interrogation
Yes

CI016 Data in the system should be
private / confidential to
another user who is not
authorized.
High Security Yes
CI017 System administrator should
be able to share Data with
particular criteria
High Security Yes
CI018 Data Viability should be
controlled with user’s Role
Hierarchy
High Security Yes
CI019 Only authorized users should
be able to Create, Edit,
Delete, and View data
High Security Yes
CI020 The system should allow
multiple users to perform all
activities with high
performance
High Performance Yes
CI021 Users/agents as well as
managers should see
dashboard i.e. graphical
representation of report on
salesforce UI and mobile
device. Assign cases to queue
automatically and notify
user/ agent by email using
salesforce automation.
Medium Functional Yes
CI022 System administrator should
be able to apply secured
access to the personalized
information based on agent
profile to an application, data
like cases, contacts, chat
High Non
Functional :
Security
Yes

transcripts, session
information for read, write,
and update operations.
CI023 System availability
requirement: System should
be available 24/7 365 days
(99.99%)
High Non
Functional
Yes
CI024
System should allow DEV,
SIT, UAT, production
Environments.
Low Non
Functional
Yes
CI025 System should allow
Track/configure changes
Low Non
Functional
Yes
CI026 System should allow Import,
Export, Update , Export All
Data
Low Functional Yes
CI027 System should allow Data
backup and recovery
requirement
Low
Functional
Yes
CI028 System should allow
Schedule Reports and Email
them to specified users.
Low
Functional
Yes
CI029 System should allow Data
migration from Legacy
systems.
Low
Functional
Yes
CI030 System should allow to use
Application by multiple users
Low Non
Functional :
Performance
Yes
Table 4.6.1: Requirement Analysis

Chapter 5
Software Design

Chapter 5
Software Design
5.1SystemArchitecture Diagram
Figure. 5.1.1: System Architecture
Real-time integrations have higher risk and require complicated queuing
mechanisms and error handling mechanisms to account for system outage and data
errors. Often, a near real-time alternative is acceptable in the cases of “fire and forget”
patterns (e.g. a user submits a record for processing and will receive an email
notification once it has been processed successfully). This type of integration will
utilize Salesforce Apex Callouts to call remote web services.
The following sections examine the more fundamental integration building blocks:
 Creating and exposing web services using the Apex programming language
 Invoking external web services from Apex
 Outbound messaging for invoking external web services when data changes
 HTTP and REST integration
 Email integration for inbound and outbound messaging
 The Force.com SOAP APIs and associated toolkits, such as the Mobile SDK,
AJAX Toolkit, Java, .NET, PHP and Adobe Flex integrations.

 Syndication feeds via Force.com Sites
The Web services support in Apex provides a way for you to invoke business logic
on the Force.com platform from some external system.
Apex is a strongly-typed programming language that executes on the Force.com
platform. Apex is used to add business logic to applications, to program controllers in
the Visualforce user interface layer, and to write database triggers.
5.1.1 Modules in the project
 Cloud Basedintegration [9]:
Cloud-based integration is a form of systems integration delivered as a cloud
service that addresses data, process, service-oriented architecture (SOA) and
application integration use cases.
Two cloud-based integration service models are iPaaS (Integration Platform as a
Service) and dPaaS (Data Platform as a Service):
o iPaaS is a suite of cloud services enabling customers to develop, execute and
govern integration flows. Under the cloud-based iPaaS integration model,
customers drive the development and deployment of integrations without installing
or managing any hardware or middleware. The Ipaas allow small businesses to
achieve integration without a big investment in skills or licensed middleware
software.
o dPaaS delivers cloud-based integration as a fully managed service. Under the
dPaaS model, the cloud platform provider, not the customer, manages the
development and execution of integrations. dPaaS users retain transparency and
control over data through data visualization tools.
 Data Modeling:

Data modeling is often the first step in database design and object-oriented
programming as the designers first create a conceptual model of how data items relate
to each other. Data modeling involves a progression from conceptual modelto
logical model to physical schema.
 Validation Rules:
Available in: both Salesforce Classic and Lightning Experience.
Available in: Contact
Manager, Group, Professional, Enterprise, Performance, Unlimited, Developer,
and Database.comEditions.
Improve the quality of your data using validation rules. Validation rules verify that the
data a user enters in a record meets the standards you specify before the user can save
the record. A validation rule can contain a formula or expression that evaluates the
data in one or more fields and returns a value of “True” or “False”. Validation rules
also include an error message to display to the user when the rule returns a value of
“True” due to an invalid value.
After you have defined validation rules:
1. The user chooses to create a new record or edit an existing record.
2. The user clicks Save.
3. All validation rules are verified.
 If all data is valid, the record is saved.
 If any data is invalid, the associated error message displays without saving
the record.
The user makes the necessary changes and clicks Save again.
You can specify the error message to display when a record fails validation and where
to display it. For example, your error message can be “The close date must occur after
today's date.” You can choose to display it near a field or at the top of the page. Like
all other error messages, validation rule errors display in red text and are preceded by
the word “Error”.
Important
Validation rules apply to new and updated records for an object, even if the fields
referenced in the validation rule are not included in a page layout or an API
call. Validation rules don't apply if you create new records for an object with Quick
Create. If your organization has multiple page layouts for the object on which you
create a validation rule, verify that the validation rule functions as intended on each
layout. If your organization has any integrations that use this object, verify that the
validation rule functions as intended for each integration.
 Business Login with Workflow Rules and Triggers:

Available in: Enterprise Edition, Unlimited Edition and Developer Edition
Organizations.
Workflow Rules and Triggers define rules that trigger Time-Based
Workflow actions off of any date or date/time field on the Object.
For example, use Time-Based Workflow to generate critical date reminders that
remind the Opportunity owners when a large Opportunity (amount greater than $1M
USD) is 14 days away from the intended Close Date. Use the same rule to notify the
executive sponsor and change the ownership of the Opportunity if the Close Date is
just 10 days away.
Review the below FAQ to learn more about commonly asked questions, including
some tips and considerations on this topic.
 Reports and Dashboards[10]:
What is a report?
A report is a list of records that meet the criteria you define. It’s displayed in
Salesforce in rows and columns, and can be filtered, grouped, or displayed in a
graphical chart.
Every report is stored in a folder. Folders can be public, hidden, or shared, and can be
set to read-only or read/write. You control who has access to the contents of the folder
based on roles, permissions, public groups, and license types. You can make a folder
available to your entire organization, or make it private so that only the owner has
access.
What is a dashboard?
A dashboard is a visual display of key metrics and trends for records in your org. The
relationship between a dashboard component and report is 1:1; for each dashboard
component, there is a single underlying report. However, you can use the same report
in multiple dashboard components on a single dashboard (e.g., use the same report in
both a bar chart and pie chart). Multiple dashboard components can be shown together
on a single dashboard page layout, creating a powerful visual display and a way to
consume multiple reports that often have a common theme, like sales performance,
customer support, etc.

Like reports, dashboards are stored in folders, which control who has access. If you
have access to a folder, you can view its dashboards. However, to view the dashboard
components, you need access to the underlying reports as well. You can also follow a
dashboard in Chatter to get updates about the dashboard posted to your feed.
Each dashboard has a running user, whose security settings determine which data to
display in a dashboard. If the running user is a specific user, all dashboard viewers see
data based on the security settings of that user—regardless of their own personal
security settings. For this reason, you’ll want to choose the running user wisely, so as
not to open up too much visibility. For example, set the Sales Manager as the running
user for a leaderboard for her team. This allows her team members to view the
leaderboard for their individual team, but not other teams.
Dynamic dashboards are dashboards for which the running user is always the logged-
in user. This way, each user sees the dashboard according to his or her own access
level. If you’re concerned about too much access, dynamic dashboards might be the
way to go.
 Security and Access Control:
Salesforce provides quite elaborated security features, as compared to the access
controls provided by database management systems or file systems.
If Salesforce data validation when applied appropriately, make data more secure and
data security more transparent to the general user. Key points for access
control are:
1. Who is accessing
2. What data is being accessed
3. How data is to be accessed
The Force.com platform makes extensive use of data sharing rules. Each object has
permissions and may have sharing settings for which users can read, create, edit, and
delete. These settings are enforced when using all standard controllers.
When using an Apex class, the built-in user permissions and field-level security
restrictions are not respected during execution. The default behavior is that an Apex
class has the ability to read and update all data within the organization. Because these
rules are not enforced, developers who use Apex must take care that they do not

inadvertently expose sensitive data that would normally be hidden from users by user
permissions, field-level security, or organization-wide defaults.
 Data Management:
Data management is the development and execution of architectures, policies,
practices and procedures in order to manage the information lifecycle needs of an
enterprise in an effective manner.
5.2Diagrams
i. Entity relationship diagram
Figure 5.2.1: Entity relationship diagram

ii. Data Flow Diagram
Figure. 5.2.2: Data Flow Diagram
iii. UML diagram
a. Use case diagram

Figure. 5.2.3: Use Case Diagram
b. Class Diagram
Figure 5.2.4: Class Diagram
c. Package diagram

Figure 5.2.5: Package Diagram
d. Sequence diagram
Figure 5.2.6: Sequence Diagram
e. Communication diagram:

Figure 5.2.7: Communication Diagram
f. Activity diagram

Figure 5.2.8: Activity Diagram
g. State machine diagram

Figure 5.2.9: State Machine Diagram
h. Component diagram
Figure 5.2.10: Component Diagram
i. Deployment diagram

Figure 5.2.11: Deployment Diagram
5.3MathematicalConceptUsed:
The best Salesforce Architectures are not based upon incumbent technology,
singular architecture approaches, or corporate politics. The best Salesforce
Architectures are based upon delivering business value. What this means for the
architect is to focus on what are the business’s requirements, roadmap, and needs for
which you will offer technical capabilities. In other words – you need to see where the
business wants to drive, and figure out which highways and roads are necessary to
support the amount of traffic. Idealistic architecture (for example, 100% Services
Oriented Architecture) may cripple your ability to provide the capabilities needed by
your business when they need them.
Good Salesforce architects have learned that the best integration designs
support both batch and service-based patterns. This means having multiple types of
middleware at work. I have had clients with three to four different integration
platforms in their Salesforce architectural landscape. This is because no single
solution can effectively meet all of your requirements, and once again the idealistic
architectures are not as important as supporting the business’s needs.
Let’s take a look at a reference Salesforce Integration Architecture. This may
or may not look like your existing landscape – however this reference is based upon
years of work at many Fortune 500 companies. The reference design also does not
recommend one technology vendor or solution over another – rather the goal is to
understand the technical capabilities that you can (and probably should) consider as
your Salesforce Platform landscape matures.

Figure 5.3.1:Salesforce Platform Landscape
5.4FeasibilityStudy
Basically the connector have 3 functions that you can utilize:
1) Remote System Reference:
We typically refer to this as the "synchronization" functionality, which is bi-
directional. This allows you to create an association between an EXTERNAL
SYSTEM issue and any Salesforce.com object (e.g. Case, Account, Solution,
Opportunity, custom objects, etc.). Once associated, you can then "share" information
across the two systems such that when the Salesforce.com object is updated, the
EXTERNAL SYSTEM issue is updated as well.
2) Remote Object Links:
This is part of the "non-synchronization" stack that is available for
EXTERNAL SYSTEM 4.3 and higher. This allows you to create "Custom Fields"
which are used to associate a EXTERNAL SYSTEM issue with any Salesforce.com
object. This can either be a 1 to 1 (using the Remote Object Link custom field) or 1 to
many relationship (using the Multi Remote Object Link custom field). Using this
method, you are still able to see the various attributes of the Salesforce.com object
(configurable to display various fields of the object), however you will not be able to
update the fields of the linked Salesforce.com object from within EXTERNAL
SYSTEM (you will have to log into Salesforce.com todo this).

3) Remote Issue Links
This is the simplified version of the Remote Object Link option and is only
available for EXTERNAL SYSTEM 5.0 and later. Like the Remote Object Link, it
provides a read-only view of linked Salesforce.com objects and supports many to
many associations. Unlike the Remote Object Link, it is very simple to configure (this
method only requires the Connection to be configured) and it stores some of the
information from the Salesforce.com object so that it is still accessible if Salesforce is
unavailable. For example, Cases will continue to display the Subject field.
1) You need to have a proper object model, where you will store the data or fetch the
data and show it on reports and dashboard. Salesforce provides one of the best report
system.
2) You can also integrate Salesforce with your system using APIs
3) Ensure which edition will suits you best, just to ensure that cost of the project will
be minimal which is the main goal of Salesforce.
4) Salesforce have APIs which can be used to interact with iPad or iPhone.
5.5SoftwareDevelopmentLifeCyclePhase

Figure 5.5.1: Software Development Life Cycle
1) Requirement gathering and analysis: Business requirements are gathered in
this phase. This phase is the main focus of the project managers and stake
holders. Meetings with managers, stake holders and users are held in order to
determine the requirements like; who is going to use the system? How will they use
the system? What data should be input into the system? What data should be output
by the system? These are general questions that get answered during a requirements
gathering phase. After requirement gathering these requirements are analysed for their
validity and the possibility of incorporating the requirements in the system to be
development is also studied. Finally, a Requirement Specification document is created
which serves the purpose of guideline for the next phase of the model.
2) Design: In this phase the system and software design is prepared from the
requirement specifications which were studied in the first phase. System Design helps

in specifying hardware and system requirements and also helps in defining overall
system architecture. The system design specifications serve as input for the next phase
of the model.
3) Implementation / Coding: On receiving system design documents, the work is
divided in modules/units and actual coding is started. Since, in this phase the code is
produced so it is the main focus for the developer. This is the longest phase of the
software development life cycle.
4) Testing: After the code is developed it is tested against the requirements to make
sure that the product is actually solving the needs addressed and gathered during the
requirements phase. During this phase unit testing, integration testing, system testing,
acceptance testing are done.
5) Deployment: After successful testing the product is delivered / deployed to the
customer for their use.
6) Maintenance: Once when the customers starts using the developed system then the
actual problems comes up and needs to be solved from time to time. This process
where the care is taken for the developed product is known as maintenance.
Development Process in Salesforce.com:
Developing applications on the Force.com platform is easy, straightforward, and
highly productive. A developer can define application components, such as custom
objects and fields, workflow rules, Visualforce pages, and Apex classes and triggers,
using the point-and-click tools of the Web interface. Simple changes can be
implemented and deployed immediately without affecting other users in the
production organization. More complex features can be left in development status until
they have been fully tested, and then deployed to everyone in the production
organization.
Whether you are an architect, administrator, developer, or manager, this guide
prepares you to undertake the development and release of applications on

the Force.com platform. It starts with the most basic scenario, using a developer
sandbox and change sets. Later chapters address other development environments,
tools, and processes for more complex enterprise scenarios.
Figure 5.5.2: SDLC of Salesforce

Chapter 6
Implementation
Chapter 6
Implementation
Going through the class diagrams and system modules as described in previous
chapters the implementation further continues as the system architecture below:

6.1 Working of ProposedSystem:
quality.
Each application can have data, business logic, presentation, and security layers,
all of which are possible targets for integration. This project is an overall launch point
for exploring the various integration options related to Force.com and other Salesforce
One of the most frequent tasks Force.com developers undertake is integrating
Force.com apps with existing applications. The tutorials within this workbook are
designed to introduce the technologies and concepts required to achieve this
functionality.
The Force.com Integration Workbook is intended to be the companion to the
Force.com Workbook. The series of tutorials provided here extend the Warehouse
application by connecting it with a cloud-based fulfillment app.
An application for the management of warehouse is developed in the force.com
platform provided by the Salesforce.com which is a cloud based platform. This
application keeps a record of the total merchandise available in the warehouse. The
user can create an invoice and can add the merchandise that are to be sold as line items
to the invoice. As the invoice’s status is changed to close, the total number of
merchandise left in the warehouse is updated and the invoice total is displayed.
The part of the application works in the internal/base system, but
simultaneously the application integrates with an external system – Heroku, where the
order id of the invoice is automatically generated and updated. The order id can be
used by the external system for further processing like online payment etc.
Cloud based integration helps to integrate 2 systems in a much secure and easy
manner. All the features of the cloud based system such as security, 24X7 customer
service, less TOI (Total Cost of Investment) etc. are by default incorporated in the
proposed system.

Figure. 5.1.1: Working of Proposed System
6.2 Implementation
The following screenshots explain the implementation of the system in detail:
A] Salesforce.com’s Login:

Figure 6.2.1: Salesforce login
B] Creating New App:An app should be created to distinguish separate functionality
and add logo to provide branding to the application.
Solution Approach:
Create and Upload Logo of size less than 20 KB
Create New Force.com App from following click path:
SetupCreateApp  New
Figure 6.2.2(a) App Creation

Figure 6.2.2(b) App Creation
Figure 6.2.2(c) App Creation
Figure 6.2.2(d) App Creation
Select profiles and Tabs need to be visible for application

C] Application Home Page:
Figure 6.2.3 App Home Page
D] Add Merchandise:
Fig. 6.2.4(a): Adding Merchandise

Figure 6.2.4(b): Adding Merchandise
E] Create Invoice
Figure 6.2.5(a): Creating Invoice

Fig. 6.2.5(b): Creating Invoice
F] Integrate With Heroku:
Figure 6.2.6(a): Integration with Heroku

Fig. 6.2.6(b): Integration with Heroku
A] CBI Dashboard:
CBI dashboard shows real time Data Analytics.
Graph 6.2.1: CBI dashboard

B] Heroku Dashboard
Figure 6.2.7(a): Heroku dashboard.
Figure 6.2.7(b): Heroku dashboard

Chapter 7
RESULT ANALYSIS

Chapter 7
RESULT ANALYSIS
Cloud based Integration successfully integrated with Heroku using REST API
and we have determined following outcome of the system.
Reports and Dashboards offer a real-time picture of your business at a glance.
Dig deeper with detailed reports that anyone can create. And access your reports and
dashboards from anywhere.
Salesforce Security Model helps us to provide Security to Data, Access, based
on user profile, IP Address Restriction, Network IP and Sharing Settings.
Salesforce Offers 99.99 % availability with 300ms response time with high
Performance.
7.1 Testing:
The following test cases will help in better understanding of the results achieved:

Table 7.1 Test cases

Chapter 8
CONCLUSION

Chapter 8
CONCLUSION
Our fulfillment app now retrieves invoice information via the Force.com REST
API and displays it to the user. You configured your app in Salesforce to use OAuth
for authentication, and you added OAuth credentials to your app hosted on Heroku.
You can further modify your app to manipulate invoice information however we want.
With a combination of OAuth authentication, Force.comREST API, Apex
triggers, @future callouts, the polyglot framework of the Heroku platform, Force.com
Canvas, and Visualforce, you created and deployed a bi-directional integration
between two clouds.
Read the pattern summary and selection matrix if you’re considering large-
scale adoption of Salesforce-based applications (or the Force.com or Database.com
tool sets) so that you can become familiar with the integration capabilities and options
available.
Architects and developers should consider these pattern details and best
practices during the design and implementation phase of a Salesforce integration
project. If implemented properly, these patterns enable you to get to production as fast
as possible and have the most stable, scalable, and maintenance-free set of applications
possible.
Salesforce’s own consulting architects use these patterns as reference points
during architectural reviews and are actively engaged in maintaining and improving
them. As with all patterns, they cover the majority of integration scenarios, but not all.
While Salesforce allows for user interface (UI) integration—mashups, for example—
such integration is outside the scope of this document. If you feel that your
requirements are outside the bounds of what these patterns describe, please speak with
your Salesforce representative.

Chapter 9
PROJECT MANAGEMENT

Chapter 9
PROJECT MANAGEMENT
9.1ProjectPlan:
The project plan will contain all stages throughout the project lifecycle like
requirement analysis, design, implementation, testing, development, etc.
It will also contain resources, roles, responsibilities, timeline of deliverables, system
requirements.
Project management:
High level project plan (project deliverables and timelines):
Sr.
no.
Deliverables
Ownersi
gnoff
Start date Enddate Status Comment
1
Requirement
analysis and
required doc
creation and
signoff
Business 30/8/2015 6/9/2015 Done
2
High level
design and HLL
signoff
Business 7/9/2015 21/9/2015 Done
3
Low level
design and LLL
signoff
Business 22/9/2015 3/10/2015 Done
4
Development
and unit testing
phase 1
Business 4/10/2015
18/10/201
5
Done
5
Development
and unit testing
Business
19/10/201
5
30/10/201
5
Done

phase 2
6
SIT case
creation and
execution test
case signoff for
SIT
Business
31/11/201
5
7/12/2015 Done
7
UAT and
signoff by
business
Business 8/12/2015
12/12/201
5
Done
Table 9.1.1: High level project plan (project deliverables and timelines)
9.2 PERTChart
Fig. 9.2.1 PERT Chart

Chapter 10
References

Chapter 10
References
1. www.salesforce.com[Accessed: August 15th 2015]
2. www.developer.salesforce.com[Accessed: August 17th 2015]
3. www.heroku.com[Accessed: August 23rd 2015]
4. https://developer.salesforce.com/page/Integration[Accessed: August 19th 2015 ]
5. http://www.salesforce.com/in/platform/services/how-you-integrate/[Accessed:
August 20th 2015 ]
6. https://developer.salesforce.com/page/Integrating_with_the_Force.com_Platfor
m[Accessed: August 19th 2015]
7. https://developer.salesforce.com/page/Data_Integration[Accessed: August 24th
2015]
8. http://www.salesforce.com/in/cloudcomputing/[Accessed: August 28th 2015]
9. https://en.wikipedia.org/wiki/Cloud-based_integration [Accessed: April 25th
2016]
10. https://developer.salesforce.com/trailhead/en/reports_dashboards/reports_dashbo
ards_overview [Accessed: April 27th 2016]

Pralesha slideshare

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (16)

Similar a Pralesha slideshare

Similar a Pralesha slideshare (20)

Último

Último (12)

Pralesha slideshare