For Internal Use Only

SOLUTION OVERVIEW

ONLINE STORE V2.0

ISSUE 0.2

DRAFT

Ritzie Edson V.
Lamina

1 of 25
 For Internal Use Only

Contents
1 Introduction......................................................................................................................................3
2 Scope ..............................................................................................................................................4
2.1 Listing of integrations ............................................................................................................6
3 Online store - Integration details .....................................................................................................7
3.1 Online portal integration (1)...................................................................................................7
3.1.1 User onboarding data flows ..................................................................................12
3.1.2 Single Sign on .......................................................................................................13
3.2 ERP integration (2 - Orders and Customer data) ...............................................................14
3.2.1 Order numbering ...................................................................................................15
3.3 ERP integration (3 – Shipping, Products and price) ...........................................................15
3.4 Payment integration (4 – payment).....................................................................................16
3.5 Salesforce integration (5) ....................................................................................................18
3.6 Tax integration (6) ...............................................................................................................18
4 Other items....................................................................................................................................19
4.1 BOM structure .....................................................................................................................19
4.2 Address validation...............................................................................................................20
4.3 Tax display ..........................................................................................................................20
4.4 Chat providers.....................................................................................................................20
4.5 Customer hierarchy.............................................................................................................20
5 Appendix........................................................................................................................................21
5.1 Solution Overview Diagram.................................................................................................21
5.2 BOM structure analysis .......................................................................................................22
5.3 Tax display recommendations ............................................................................................23
5.4 Address synchronisation .....................................................................................................24

2 of 25
 For Internal Use Only

1 INTRODUCTION
Online store platform is a strategic initiative to enhance our offering to customer and
professions. The existing stores are a combination of B2B and B2C stores offered on a per
country basis. The existing stores are offered from our ERP system. This tight integration
with the ERP system creates a limitation on availability and extensibility of the store
platform.
In order to extend customer experience, a new store platform is to be integrated with the
online platform and support existing functionality to create a unique experience for the user.
Critical to the new store platform is the integration between various systems to ensure
customer shopping experience is uncompromised.
This document outlines the various integrations for the new store platform. The solution
design is intended to be a living document that changes as new requirements are added to
provide a holistic view of all the aggregations.
This document:
1. Details the Integrations with various platforms
2. Provide details of integration mechanisms (as appropriate)
3. Details the choices and the decision criteria for the choices
4. Map requirements to the solution choice (when requirements become available)
5. Provide the optimal solution for the requirement
6. Serve as a reference for the choices
This document not meant to:
1. Serve as a detailed document

3 of 25
 For Internal Use Only

2 SCOPE
This store needs to integrate with internal and external components (hosted and
managed). These integrations are shown in the Figure 1. Logical view of online store
integrations.

Salesforce

Orders and
Customer data
sync
5
1
2
ERP
Online
Online Store
Portal
3 · Shipping data sync
Online user Onboarding · Products and price

SSO
6 4

Tax Payment

Figure 1. Logical view of online store integrations

The Magento store needs to be a highly available platform. Due attention needs to be given
to each of the integration components to ensure the store is highly available and reliable.

In order to maintain the high availability of the platform following are the integration choices:

1. Batch integration: Where reliability of transactions is required and where the transaction
are not time critical, batch mechanisms are used (example of this are order integrations
to ERP)

2. Real-time integration: Need to be performed with a time constraint (such as payment

processing, address validation). In such cases the reliability of the intergration provider is
also taken into account.

The Integration components and the type of integration are listed in the next section.

4 of 25
 For Internal Use Only

Anonymous user

Web requests (access to

Recipient, Professional,
Staff content)

SSL
F5
Terminato
r Authentication
identity

IBM SAM IBM - SIM

Customer data
transferred using HTTPS traffic
magento
extensions

Portal

VPN

Integration with
Magento Oracle
Email server
External
Saleforce
hosting

1
Figure 2. Solution overview

1
Logical architecture dependent on business requirements and infrastructure analysis

5 of 25
2.1 Listing of integrations
These integrations are within systems.

1. Online portal:

a. User onboarding

b. Single Sign on

2. ERP:

a. Order integration

b. Customer address update

3. ERP:

a. Shipping integration

b. Products & Price integration

4. Payment:

a. Payment gateways integration

5. Salesforce integration:

a. Customer details sync

6. Tax

a. Tax calculation integration

The next section discusses the details of these integration

6 of 25
3 ONLINE STORE - INTEGRATION DETAILS
The integration options have been discussed across various teams and a reference to the
discussed list is located at in Confluence. This section discusses the details of these
integrations and refers them as needed.
The numbers align with the integration number in the previous section.

3.1 Online portal integration (1)

The online store integration with Portal is needed for:
· User onboarding
· Single sign on
User onboarding is the method to provision the users onto a system. Provisioning users is a
complex activity that requires account creation with proper details. These details would need
to be sources from a different system. While it is possible for the account the be provisioned
manually, its inherent complexity would make it error prone.

Hence there needs to be an automated method of provisioning the account. This method is
responsible for creating the account after validating all user details. Traditionally user
accounts have been provisioned on a system basis (i.e. account provisioned for one single
activity). This approach works when the system is specialised (performs one of few
operations). However when there is an array of platforms that perform a multitude of
activities, the practice of manually provisioning user on a per-platform basis doesn’t scale.

The onboarding functionality needs to account for a staggered launch of any of the platform
across a as many regions as possible. Support activities (for provisioning/user maintenance)
need to be kept to a minimum hence the approach to allow user access based on the groups
they belong to.

An automated means is needed to provision a user across many platforms. Currently this
activity is performed by the user onboarding component of the online portal. The solution is
reused to provision the user across multiple platforms as shown in the process below.

7 of 25
 For Internal Use Only

Onboarding flowchart

Phase
Retrieve
Add user
Function

Is user salesforce
Accept Validate onboarding
start associated yes campaign name, stop
user the user request to
with a add roles to be
data details the TIM
Salesforce provisioned to
workflow
campaign? the request
queue
no

CSR Approval
approval complete
?

no
Validate Provision
Retriev validate Is valid request Match year Exactly Provision Provision Send welcome stop
start Is yes receipien yes account in all
Function

e request of one RP user to emails

yes receipient? t details online
request activation match? user groups
systems
account

The istore sync would have

to work for sometime till
Validate
no no all of CAM users are
carer
migrated
details
[to be decommissioned
later on]

Figure 3 Onboarding flowchart

8 of 25
There are two aspects of on-boarding the user:

1. Provisioning the user: Creating and maintaining of the user identity that is required for
the user

2. Allowing access for the user: Enabling the user to gain access to a system

The distinction between the above steps is provisioning creates the user but the user isn’t
allowed to access till the access is granted. The user obtains (or surrenders) access based
on his role. The user role is controlled by the user onboarding pages – the role based access
control (RBAC) principles are reused.

The access is manages via junctions – a standard feature of webseal. Each junction
is associated to a group enabling a user with a specific role to access the system resource
(as
shown in the diagram below).
RBAC: Junctions used to allow
access to applications, junctions
use user groups to decide if a
user has access
Applications know what to
render based on the user

1 Recipient
Portal

2 Store
Webseal

F5
Portal user
3 System X

4 System Y

Figure 4. Access to systems based on roles of a user

As roles are used to gain access, the support activity required to grant access to a
user reduces significantly. Support users wouldn’t need to perform the provisioning action as
this is performed during onboarding further reducing the change of errors.

9 of 25
The onboarding application can be maintained independently and updated as needed. This
allows the ability to provision for a controlled group.

Figure 5. Options for onboarding

The onboarding application would have to provision for guest users (who would need ERP
accounts to be created). The portal could be inundated with requests resulting from
fake users signing on. While the idea is to encourage using the store, a process is required to
prevent exhaustion of the user licenses 2.

The business flow for provisioning is depicted in the figure below:

2
To be discussed during requirements elaboration

10 of 25
 For Internal Use Only

Onboarding application

Phase
Onboarding application

User email validated with

salesforce; Form submitted to TIM
Fills in form for onboarding Retrieve groups from workflow
application salesforce
TIM workflow

Validate request User provisioned in all User groups

systems; access granted to provisioned
select systems

Webseal
User access

User only allowed access

to application/systems
based on their role

Figure 6. Unboarding application

11 of 25
 For Internal Use Only

3.1.1 User onboarding data flows

The data flows are divided across two components user-onboarding and the workflow. The former is required to onboard the user and
the latter to provision the user across different systems. Development can be controlled in user onboarding (deployed on portal). The
provisioning workflow (performed by TIM workflow) would need to change when a new system is introduced.

User Identity
onboarding ERP Store Community
manager
form

Enter details Validate user

details

Salesforce campaign
validation needed

Retrieve salesforce campaign

Validate user details

User details returned, (all details needed to provision users across

systems)
Submit request to provision user

Validate user details

Provision user

Provision user

Email confirmation of account

creation

User onboarding functionality TIM provisioning functionality

Figure 7. User provisioning flows

12 of 25
 For Internal Use Only

3.1.2 Single Sign on

Single sign on can be achieved either by having all system behind an authentication gateway or using SAML. This is shown in the figure
below:

Option 1: Use a common hosting provider Option 2: Use SAML (requires TFIM)
Web requests (access to
Web requests (access to Recipient, Professional,
Recipient, Professional, Staff content)
Staff content)

F5 SSL
Authentication
identity terminator F5
TFIM identity

IBM SAM IBM - SIM

IBM - SIM

HTTPS traffic Portal Portal

Customer data
transferred using Customer data
magento transferred using
extensions magento
extensions

VPN
VPN
Magent Integration with
Email server ERP Magent
o Integration with
o
External Email server
Saleforce External ERP
hosting Saleforce
hosting

Figure 8. Single sign on options

Having a single point of entry (option 1) has the advantage of cost but is restrictive as it requires all systems to be front-ended by
Webseal. Having SAML provides flexibility of hosting the solution with different providers. The SAML approach can be extended as
additional customer facing platforms need identity services.
The downside of the SAML approach is cost and the need to procure additional software. However, strategically this is the
recommended approach as it reduces rework in the future.

13 of 25
 For Internal Use Only

3.2 ERP integration (2 - Orders and Customer data)

ERP integration is required as part of the order management. This involved bringing the orders from
Magento to the ERP instance. The Mechanism is shown in the figure below:

Order and address integration

Order sync
component

Magento ERP

Figure 9. Order integration with ERP

The order integration is performed via a batch interface. Reliability of the interface is the main
consideration for choosing this interface. Staging tables are used to minimise impact to the database
as per standard process for batch integrations. The various approaches are listed in the figure below:

Figure 10. Options for the batch interface between Online Store and ERP

This interface performs operation in a two-step manner. The operations are listed below

1. Upload the transactions

Purpose: Extract and upload the online store transactions on a FTP server.

Steps:

· Extract transactions not yet extracted

· Aggregate all transactions into one timestamped file to be uploaded

· Ensure upload complete successfully

14 of 25
 For Internal Use Only

· Raise alerts as needed

2. Import the transactions to ERP

Purpose: Load the transactions to ERP database

Steps:

· Download the file from the FTP server

· Process transactions in the file

· User Oracle APIs to create the order in the ERP system

· Ensure all-or-nothing integrity i.e. either all the transactions in the file are processed or none
get processed

· If there are new shipping address, add to the address to the customer’s address

3.2.1 Order numbering

Orders numbers will be maintained independently. The orders in ERP will contain a
reference number to the magento sequence to identify the order origination.
This is an outcome from the preferred options selection below

Figure 11. Options order numbering

3.3 ERP integration (3 – Shipping, Products and price)

Shipping products and price will be a batch integration using the FTP based transfer for
reliability.
These two integrations are separate from one another as they occur with varying frequency.
They are represented in the figure below:

15 of 25
 For Internal Use Only

Shipping, products and price

Magento ERP

Figure 12. ERP integration Shipping status, products and price

The products and price integration bring across any changes (delta) in the products and
base price setup in ERP. For the B2C store, prices are maintained in online store with only
the base price imported.

Figure 13. Integration option

3.4 Payment integration (4 – payment)

Payment is in from Oracle. Any deviation will create a significant organisation change. In
order to minimise the organisational impact, the intent is to reuse the existing method for the
change.
Payment integration would be a two-step process with the magento store authorising the
payment and oracle fulfilling the payment. This represented in the figure below:

16 of 25
 For Internal Use Only

Payment
information
passed to Oracle

authorization Settlement (at

Magento time of
shipping)

Payment gateway

Figure 14. Payment integration

Since the integration is a two-step process, it implies Oracle would need to integrate with the
payment provider as well.

Figure 15. Payment gateway integration options

17 of 25
 For Internal Use Only

3.5 Salesforce integration (5)

Salesforce is a CRM platform. Integration with Salesforce would be via magento extensions.

Customer data
transferred
using magento
extensions

Magento
Email server
Saleforce Bulletproof

Figure 16. Salesforce integration

The extensions will be tested out before they are implemented. This is utilising the buy vs
build principle.

3.6 Tax integration (6)

Tax is a both a complex topic and one that requires validation. There are various approaches to tax
each with their own pros and cons. A decision for the solution is yet to be arrived at for tax. It would
be a combination of the solutions mentioned.

The tax processing is represented below:

Possibility of errors needs

exception handling

1 2 3

Tax computed and Order along with Tax Proceed

Address validated applied in Magento tax sent to AR recalculated with
with Vertex shipment

Store process ERP process

Figure 17. High level tax calculation process

The tax computation scenarios are:

18 of 25
 For Internal Use Only

3
1. Magento can compute tax using tax rates

2. Off load tax computation to third party (Vertex/Avalara)

These investigation options are listed below:

Figure 18. Tax integration options

4 OTHER ITEMS
This section lists the other items that form part of the solution.

4.1 BOM structure

When orders flow into ERP, they need to fit in a BOM structure. The current BOM structure
specifies a hierarchy of items. This requires a translation in order for the Magento orders to
fit into the ERP BOM structure. This amounts to additional effort developing and testing this
layer. If a flat BOM is used, the need to perform this order is reduced.
A comparison between the various is presented in BOM structure analysis

3
Magento Tax best practices (http://www.magentocommerce.com/knowledge-base/entry/magento-ce-18-ee-
113-tax-calc, http://www.magentocommerce.com/knowledge-base/entry/ce18-and-ee113-tax-config-us)

19 of 25
 For Internal Use Only

4.2 Address validation

Address validation needs to be performed US store. This validation can be performed by using a
4
Magento extension (such as UPS address validator ).

4.3 Tax display

US and Canada would display prices excluding tax whereas other store would display tax on
the product prices. This configuration will be controlled on a per store basis.

4.4 Chat providers

Magento will integrate with external chat providers via extensions or via integrations to the
webpage. The UI impact has to be assessed on a case by case basis.

4.5 Customer hierarchy

The solution would support customer hierarchies (both B2B and B2C). This would allow a
clinician to place orders on behalf of a clinic. It would also allow a carer-recipient relationship
allowing for a carer to transact for a recipient.
This hierarchy is initially setup during the onboarding of the user.

4
http://www.magentocommerce.com/magento-connect/ups-address-type-validator-7645.html

20 of 25
 For Internal Use Only

5 APPENDIX
5.1 Solution Overview Diagram

Rolling out
store to
countries
Web requests (access with
to Recipient, online
Professional, Staff services
content)

F5
Authentication
identity

IBM SAM IBM - SIM

Customer data
transferred HTTPS
using magento traffic
extensions
Portal

VPN

Integration with
Magento Oracle
Email server
Saleforce Bulletproof

Figure 19. Online Store - Solution Overview

21 of 25
 For Internal Use Only

5.2 BOM structure analysis

BOM structure analysis has the following activity effort:

22 of 25
 For Internal Use Only

5.3 Tax display recommendations

5
Figure 20. Tax recommendations

5
http://www.magentocommerce.com/knowledge-base/entry/magento-ce-18-ee-113-tax-calc

23 of 25
 For Internal Use Only

5.4 Address synchronisation

Address synchronisation is a complex mechanism. The store platform isn’t intended to replicate all
of Oracle’s address. In order to prevent real-time integration for address, the store platform needs to
keep a local copy of the addresses (billing, shipping). The customer is allowed to make changes to
the shipping when placing the order. It is important that this address makes it way along with the
order.
The customer service can update the address this needs to be propagated to the store. These
updates happen via different means.
The shipping address update would happen with the order, whereas the customer service update is
synced through Salesforce and then to the store via the Salesforce plugin.
Various scenarios arise due to the time of these address updates. These scenarios and the
desirable outcomes would be tabled and discussed at a later stage.

24 of 25
 For Internal Use Only

The high level address sync is visualised in the diagram below:

Customer
Users service

F5 Customer sync

IBM SAM

Portal
Address sync via plugin
Product additions/modifications; shipping
status; base price

ERP
Integration
scripts, Shipping
order update

Order update

Figure 21. Address sync

25 of 25