Web App API and front-end pages

Hello,

For now APIs are not available for use in front-end, but we're really interested to find out more about how you plan to use those as we might have in plan something you might use.

Cristinel

Hi Crsitinel

Just to add to this. Currently we do a lot of the following and it would be awesome to be able to do it all within BC without third party servers.

Let's say we're on a webpage that has a webform.

When the client enters their email address we Ajax out to an externally hosted PHP server where we run a script.

The script queries the BC API and matches up an email address.

Once we find the user in the database we can do do a lot of stuff with it. Usually we check if the user exists and if they're part of a secure zone. If they are we report back to the front end this information ***You already have an account with XXXXX - why don't you try logigin in before trying to create an account****

We also do other stuff. Like we store data we've captured previously in Custom Ext CRM fields and using the same technique above we'll pull that data back out to the front end and can notify a lot of things, we can also use this querying of the information in the database to make assumptions on things. IE if we know their email is in the Database when they're filling out the webform we can offer up messages "welcome back". Then based on things they've done before on the website that we've stored in Custom CRM fields we can customise their experience and prepopulate webforms to some extent too.

ITS REALLY REALLY POWERFUL. I only wish we could query the CRM Database direct. It takes a while to build this all out with an ext PHP server and creates another point of fail.

It would be a game changer if BC could open up the API to query and return some CRM assets from the front end. ALSO, if you layer Liquid on top of being able to do that then you've got a real winner.

PS - I've said it for years that BC should give us some PHP hosting with every site to allow us to do some custom stuff without having this code run external.

But even better would be to have the ability to look backend from the front.

What's the chances of making that happen?

Happy to chat about this.  Here's some code we use to make this happen.

<?php

/*

This script checks to see if a person (email) has a password. If so it will display the required message

*/

if (!empty($_REQUEST['email'])) {

    //echo " hello";

    $email = $_REQUEST['email'];

    //$email = "xxxx@xxxx.com";

    // load NuSOAP

    require_once("../NuSOAP/nusoap.php");

    // Setup API connections

    $soap        = new nusoap_client('https://xxxxxxxxxxx.worldsecuresystems.com/CatalystWebService/CatalystCRMWebservice.asmx?W SDL', true);

    $username     = 'xxxx@xxxx.xxx';

    $password     = 'xxxxxxxx';

    $siteId     = xxxxx; // xxxxx xxxxxxx

    // Retrieve Client Info

    $client    = $soap->call    (    'Contact_RetrieveByEmailAddress',

                                        array    (    'username'            => $username,

                                                    'password'            => $password,

                                                    'siteId'            => $siteId,

                                                    'emailAddress'        => $email

                                                )

                                );

    //print_r($client);   

    $clientPassword = $client['Contact_RetrieveByEmailAddressResult']['password'];

    if (!is_null($clientPassword)) { echo "You already have an account with XXXXX - why don't you try logging in before trying to create an account"; }

    else { echo "nothing"; }

    /* this shouldn't be needed as we can see the password field in the client details

    $zones    = $soap->call    (    'Contact_RetrieveZonesByEntityID',

                                        array    (    'username'            => $username,

                                                    'password'            => $password,

                                                    'siteId'            => $siteId,

                                                    'entityId'            => 'xxxxxxx'

                                                )

                                );

    print_r($zones);   

    */

    exit;       

    //loop through forms until we find the right one

}

?>

Brett

I would not load a classifieds with 10,000 records onto BC, I recommend you make your own system or hire someone to make it. BC is good at most things but there is no real way to store that data as (currently) there is no API access to any webapps so even if you were to make a custom system there would be no way to import the existing data or allow for a data sync (in your case with filemaker). You could try to hack it into another data system like shop products, have each classified ad as a product, but it just like a mega hack to me.

If you really want to use BC or must for whatever reason you could do a hybrid like Brett was talking, keep all your content off BC on a 3rd party server and use it to pull in the data via JSONP, but it's a much slower experience for the users.

Hey guys.

First up - Liquid
Being server side rendering and the efforts BC are making to expose data to that is awesome. And continuing to allow more data to be accessible to Liquid and what it can do already will remove the need for a number of API use cases.

Form CRM Data Entry Exposure

We can create forms, you have update details form for users, web app update forms which lack quite a lot of ability to update a number of aspects in the actual CRM. The CRM, web apps and core modules do have features in them that you can not access on the front end, allowing forms to be able to update more etc will be another good step.

JSON

It is not there yet, there are some security issues and more scope on this but IF BC get this right, like offering JSONP options (maybe keybased access, white listing options) you will be able to have websites and web solutions that can offer basic API access for 3rd party solutions to read data as well as the API itself to do more serious interactions.

Having this internally for your own work can be useful and also pulling info from 3rd party JSON based API would also be great if possible.

Between 3rd party and BC

At the moment you have the following:

1. Front end access through modules and tags

2. Back end access

3. Open Platform

4. External solutions.

Open platform is great to create solutions for many thing using the API but open platform apps are static dormant apps in BC, which are only awake when you run them. There is no form of requests or triggers to wake them or get them to do things.
Your normal API has notification URL abilities to fire off your 3rd party solutions when things happen.

What I see as a solution is to leverage further on Open Platform.

We could create an app that would check the CRM entries and fire back a set of results, say in JSON format for example. What these need to be able to handle though is a request.

A request would need to be restricted to the sites domains (for security) where you could make a request with javascript on the front end to fire off these App Variants to action.

Apps need to be authorised and signed in BC, so Apps or a Variant of Apps (I see a config file to define it as such an app - No admin use or admin file or could also have an admin menu and render) could be able to receive or listen out for requests.
Liquid could also make a request for further information from an app for example and get a response.
I would also see that you would not be able to do certain things with these. A request for password for example would not be allowed for security reasons, but checking if CRM entry exists or check their email and fetch it would.

If you Take the good example from Brett:

You would have your web form and you would have some javascript to make a request to check if an email exists in the CRM on "blur" or "keydown" etc.

This would have a request to the app that has been created for it, maybe holding some digital signature along with a domain check to verify the request. The app would access the BC API and run its action accordingly.
The app would return a JSON response in which you can use.

In this case it would simply be a 0 or 1.

Summary:

I do see the need for some limitations on this and there will always be a place for 3rd party API, this would only be the middle ground to fill that Gap between, BC/Liquid etc and full API solutions.

I think there are lots of use cases where people are writing Solutions on 3rd party servers for small to medium applications with BC sites. Apps partially fill that void but they are not active.

Apps need the ability to listen to requests made to them to perform actions.

This along with things like Liquid I feel you would have pretty much all areas covered.

Hi guys,

First of all thank you for your examples, they are exactly what I was looking for.

To increase the excitement, in the BC Unconference, we will showcase some internal work that creates a blend between modules and APIs, making BC a lot more flexible for developers. For example, Your use case Brent can be solved with a module, some APIs and some client side code. It will also address the security concerns regarding accessing APIs in front-end.

Cristinel

That sounds cool Cristinel, I always wait till such things near production though before I get excited... Web app engine and more we have seen and then not seen before

As I've said, it's just an idea that we'll be playing around and we'll use MAX to get some feedback on it. We'll get in touch at MAX to share some thoughts on it, but we think it might be interesting.

Cristinel

Look forward to it.

What are your thoughts on the app request concept Cristinel? Is it similar or something that wont quite fit?

Why do you need an app for that? Although not sure, I believe it can be achieve in other ways.

Cristinel

if (!is_null($clientPassword)) { echo "You already have an account with XXXXX - why don't you try logging in before trying to create an account"; }

    else { echo "nothing"; }

Instead of outputting text, output javascript and embed the script on the BC page and hook events to the login to check using the BC API, it would be exactly the same as a client side BC and you wont have the cross domain issues I guess you are having with this script solution.

You can do it now, but it's a little bit of a mission to setup with an API on another server and passing the responses back to the client, in the future you wont need the 3rd party server to access the API you will be able to access it directly. So your options are to develop it now as a custom solution or wait until BC make their other API's.

Your main announce things are..

Liquid accessing a lot more data and able to do a lot more then you can now with it - A LOT MORE. It is like a massive amount more then you can do now. When you get into the thicker end of it - there is a lot!

API - API SOAP wise will got to REST and BC have already said there will be more of it.

Future stuff and what is released.. we will see, BC has some good ideas.