The document discusses integrating an existing Leads360 customer relationship management (CRM) system with a new iOS application. It proposes consuming the Leads360 SOAP web service to register new leads from within the iOS app in response to events like missed calls. When an event occurs, the app would send a request to the Leads360 service, receive a response, and create a notification in the app with the lead information. Error handling is also considered, like retrying requests if the internet is unavailable.

1. Integrating an existing System into an iOS Application*
Boris Oliver Dominguez Quiroz1
Abstract— In this article we are going to describe an inte-
gration scenario who involves an existing system and a native
iOS application. The integration is going to take place inside
the iOS application and we are going to provide more details
about it in this document.
I. CONTEXT
Long time ago an iOS project was created in order to
contact leads and clients. This small app was able to access
to the user’s calendar and also the contacts list. On the
other hand, there’s a company called Leads360 who has its
own system but they want a new iOS application with the
mentioned features above. Currently this company has an
ASMX web service who allows you to authenticate to the
system, register a lead, register a client, register a sale, etc.
Customer or Client Relationship Management (CRM) is
the most important aspect in business sales and marketing
for salesmen. According to various researches and studies,
a potential lead, prospect or e-leads who initiates a contact
to purchase your product or service is 82% more likely to
close a deal with a business, rep, salesperson or freelancer
who calls them back first. That’s why Leads360 wants to see
some notifications in the iOS application for a missed call
or email from a potential lead.
II. PROBLEM
For example you can miss a call or email from a potential
lead we would like to register that person automatically;
when an event like this occurs how do you initiate a process
in a remote system like Leads360, pass the potential lead
information to that process, receive a response from the
remote system, and then use that response data to create
a notification within the iOS application?
III. FORCES
We have to consider the following forces:
• Does the call to the Leads360 service require the iOS
application to wait for a response before continuing
processing?
• Is the call to the Leads360 service a synchronous
request-reply or an asynchronous request?
• Is the integration based on the occurrence of a specific
event like a missed call?
• Is the Leads360 service able to respond to the request
with low latency?
• Is the Leads360 service able to respond to multiple
request at the same time?
*This work was not supported by any organization
1Student of Integration Patterns, ALSIE, Cochabamba
IV. PROPOSED SOLUTION
Leads360. Fortunately, Leads360 has an ASMX web
service (no code required).
iOS Application. We need to consume the externally
hosted service (SOAP web service), so we need to define
some calling mechanisms.
A. Architecture
Basically we have a Client-Server architecture, but in
order to consume the SOAP web service we have to do the
following steps into the iOS application:
• Subscribe the iOS app to the NSNotificationCenter.
• Create the request SOAP Envelope message as NSString
• Create a request to the URL (NSMutableURLRequest)
• Add required request header elements
• Define the request method (HTTPMethod: POST)
• Define the body of the request (HTTPBody: [bytes])
• Implement the NSURLConnectionDelegate methods
(didReceiveResponse, didReceiveData,
didFailWithError, connectionDidFinishLoading)
• Parse the response (implement this inside the
connectionDidFinishLoading delegate method)
• Queue the new potential lead into the notification stack.
B. Normal Flow
This is the normal flow for a missed call event:
• We receive an event in the iOS device (a missed call).
• The NSNotificationCenter notifies the iOS application
that an event has occurred.
• The event is analyzed, and if we detect a potential lead
then we proceed to register it.
• The client (iOS application) sends a process request to
the respective server (Leads360 service) via a network
connection.
• This request is then analyzed, well processed and finally
delivered back to the client (iOS application).
• The client manages the successful response and queues
the new event into the internal stack of notifications.
C. Error Scenarios
It’s important to include an error handling and recovery
strategy as part of the overall solution. We have to think in
the following scenarios:
No internet connection. If there’s no internet connection we
have to create a new Request and add it to the PendingRe-
questQueue. So, when the internet comes back we can try
to send those requests again. It is very important not to lose
information in this point.

2. An exception during the normal flow. It can be produced
by some wrong data in the HTTPBody, so we need to catch
that NSException and add it in a log file.
HTTP Response Status Code. If the status code we
receive is not equals to 200, we have to analyze what
happened based on the status code number in order to use
our PendingRequestQueue or log some information into a log
file. We have to implement this inside the didFailWithError
delegate method.
D. Security Concerns
In this integration we have the following security concerns:
• The Leads360 service must be protected by implement-
ing the appropriate firewall mechanisms.
• In order to consume the services we have to call the
authentication service first. It will generate a token for
us, and we must use that token in the rest of the services
provided by Leads360. (like the AddLead service)
V. VERIFICATION
In order to test this specific implementation, we have to
deploy the iOS application in a real device and reproduce
the event (missed call). If the missed call event was able to
create a new lead in the Leads360 system, we are going to
be able to see a notification in the iOS application with the
identifier of that potential lead.
VI. CONCLUSIONS
This kind of integration is very common on mobile en-
vironments like iOS and Android, so if the external system
doesn’t have an EndPoint (like a web service), we should
have to implement a new one.
APPENDIX
An appendix section is not required.
ACKNOWLEDGMENT
An acknowledgment section is not required.
REFERENCES
[1] Enterprise Integration Patterns. Designing, Building, and Deploying
Messaging Solutions, Gregor Hohpe. Bobby Woolf, Ed. Boston:
Pearson Education, Inc., 2004.