I am going to develop a complex web application related to affiliates. I want to integrate sugarCRM as the CRM module of my affiliate application. I have some misunderstandings related to integration methods. From FAQs at Sugar CRM website, It is stated that there are two ways to integrate one is Webservice API and second is Module Builder.
Now let me first tell you about my understanding. If you have a standalone application running on your server and you want to integrate the CRM then you have to choose Web Services API for it. But if you have installed CRM on your server and not having any other standalone application then you can use Module Builder Method. It is just like you like you have installed any CMS and creates modules to extend the functionality.
Am I rite?
OR I am having wrong understanding about CRM integration? For standalone application we need to use only Web Services API in which we will use data using web services and show in our system?
Module Builder allows you to easily add new functionality to SugarCRM though an easy to use GUI. If you want to track company Desks, Widgets, Recordings, Headaches,....anything, you would use Module Builder to add your specific needs to SugarCRM. You can even relate these new module items to the core modules such as contacts, accounts, etc.
Web Services API is a way to access SugarCRM data and functionality from non-SugarCRM code. Web Services API can be used to Create, Read, Update, and Modify existing SugarCRM records through API calls. You can use SOAP or REST to communicate with SugarCRM. This includes accessing any newly created custom modules you built using Module Builder. With Web Services API, you could access how many resources, Widgets, Recordings, or Headaches from another internal or external application.
Web Service API is almost always the correct way, if you need to integrate with SugarCRM from an external application. This method is great for small-medium amounts of data and if you need your application to be in almost sync with sugarCRM.
Other methods exists which are better suited for larger amount of data and if "realtime" sync is not needed. However, they are usually more complex and require more development and understanding of SugarCRM.
It is e.g. possible to create a PHP batch script on the SugarCRM server, which interfaces with SugarCRM API and exports/imports the given information from/to another system.
Apart that the situation you describe is the reason why webservices exist, the ones provided by SugarCRM are extremelly flexible and allow you to access each and every feature, not only the ones provided by default, but also the ones you might develop and/or install.
Concluding, if what you really need is to perform an integration between your application and SugarCRM, you don't need to learn how to work with SugarCRM (from a developers perspective), you only need to know how to work with webservices, Soap or Rest.
Related
First of all I hope I'm allowed to ask such a broad question (first time doing so).
Ok so I'm very new to React & I need a project to work on so I thought I'd recreate my portfolio (currently created in laravel) as a react & react native app.
My questions are:
Would a Rest Api NETCORE backend be a good choice for react ?
My experience is more in ASPNET MVC than Core, should i just stick
with MVC API's for now (i've already started creating a NETCORE Api
for learning purposes)?
Would a php framework such as CodeIgniter be better for this kind of
job?
My main question is if this is a good approach? I'd like to have a basic backend (auth, news posts, portfolio items etc) and then continue building on my react apps.
I was thinking that by creating a Rest API backend it would save me a lot of trouble when trying to create a react app for PC,Android or whatever (same back-end, different client).
P.S: i'm going to host my API on Azure's free websites if its ASPNET or a shared hosting if its PHP, that is the reason for which im moving away from laravel (so laravel is a no-no).
P.S2: Firebase or other clouds (except Azure) are a no-go for me. I have access to lots of resources and i'd like to use them & not use free services like firebase or whatnot.
Just giving my 2 pence here, as this is really opinion based!
In terms of the backend, it's up to you, whatever you feel more comfortable with - but I would give a keen eye on the architecture of the backend system you build.
My choice would be to create a micro services based architecture where you create simple, atomic services which only deal within their domain. For example, you could create 'Common Services' - services which can be used as dependancies by other services (events, encryption, documents etc..) then create atomic services which deal with an aspect of your application such as User Service, Payment Service, Product Service, Basket Service etc..
The idea is simple, to create simple data driven CRUD services which are modular, atomic and reusable. I've found that learning new technology is great but understanding and learning good programming architecture is even more rewarding. You can structure data to make it the most efficient for you.
Once you have built a service, you could use services like Swagger UI to automate documentation and create testing suites for them. If you haven't used Swagger I throughly recommend it.
Implement testing for each service, and go through the whole lifecycle of software development. That will really go far in your portfolio.
Here are some articles relating to building microservices in ASP.NET Core
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/data-driven-crud-microservice
Swagger
https://swagger.io/
As a side note, I do not develop in ASP nor any other microsoft stack - but the principle is the same
UPDATE
The issue with building monolithic applications is that the code base can get more and more complicated and huge as your app grows. Some advantages of Micorservices are:
Scalability
Fault Insolation
Eliminates long-term commitment to a single technology stack
Easier for developers to understand (and document)
My type of set up would be using Spring Boot (Java) and using Eureka Server - but you are into the MS Stack, but the link I've given you above shows how to create a basic CRUD microservice with Net Core. I would give that a go, and see how it goes, then you can move to CI/CD for Azure!
Moving on from just a simple CRUD API, you can introduce WS connections with event driven updates (server to client) rather than asking for new data.
An Architect that I once worked with (a genius guy) told me never to be too reliant on a 'Framework' - they're cool when they are doing well, but a great application should be flexible to change, so I wouldn't rely too much upon a 'framework' but that was just his opinion.
Try API Platform - dockerized, but deployable to php hosting (based on Symfony), generates react-admin based admin and optional web/mobile clients (IMHO the weakest parts of this project), openAPI (swagger) docs, easily usable with graphQL ... just try.
Building portfolio with Laravel isn't a good idea. Use Gatsby - you can use graphql (WordPress, contentfull) as a source, generate static site.
What is the right way to integrate third party api in magento . Logistic API integration is provided , but need help with the right process to make it work.
Thanks in advance
Assuming that you want to consume an external API from Magento this would be the correct structure:
For Application related logic create a Module in local namespace
(/app/code/local/(vendor-name)/(module-name))
Enable your Module with an xml in /app/etc/modules/
Put your Api related libraries or logic under /lib/
Make use of Api libraries in Models under
/app/code/local/(vendor-name)/(module-name)/Model
UPDATE:
I found a sample Magento 1 Module on github, that simply consumes google weather api.
https://github.com/careys7/Magento-Weather-Sales
An alternative solution could be, especially when trying to integrate an API that's not directly supported by Magento, to use flowground. It offers flexible API integration for thousands of APIs with dedicated connectors, e.g. Magento 1 and Magento 2.
Check the list of integrated connectors and GitHub for the list of available Open-Source connectors.
An existing 8+ year old application is being migrated from a self-contained website to a webservice-oriented architecture to allow among other things, external parties access to the calculations and data within the application.
The application allows visitors to access insurance-related information, calculate price quotes and contact agents.
The original logic of the application has been extracted from the main application to a SOAP service - so far, so good.
Based on in-house knowledge of Zend FW, the choice was made to drop the legacy code with many downsides and move to a more robust and community-backed framework - Zend.
An initial Zend FW app has been built that consumes the WSDL and allows searching and displaying of customers. After that was finished we wanted to integrate external applications/modules for components such as a basic (!) cms, mass-mailings, polls etc.
As we consider those components essential for the end-product but not our own core-product, we thus want to use external applications for this.
However - looking at e.g. tomatocms and digitalus etc., they seem to require us to build our product into theirs - and we want it the other way around. CMS pages are the exception, and not the rule.
Integrating authentication among these applications seems very difficult, as each seems to want to be 'the' application.
TL;DR:
What would be the best solutions to integrate a CMS or other apps into an existing/in progress zend FW app?
I think the best solution for you is to create a structure for Modules/Plugins where you set a pattern of use and you will make your application understand these modules created following the specifications above.
With this you allow anyone to be creating or developing models desaclopados their application.
I think this is a good example with your Wordpress plugins. Anyone can create and embed its functionality within the application page, but of course you can make in its API limitations, controlling what you want.
I've designed my database diagram(11 entites) for my prototype application. I need to have an REST API on top of this that will allow me to build a prototype android tablet application that talks to it.
Considering this is only for prototype purposes. What would be the quickest way to get a API up and running that would allow me to get, put, delete etc..
Security at this point isn't an issue so even if all add edit delete were open that would be fine.
My initial idea is to build this with PHP and MySQL maybe using the Yii framework to help but I feel there might be something that might be faster for my purpose.
Any thoughts or recommendations or advice?
It is worth looking into API rapid-prototyping tools like Apify (tutorial) since you're starting from scratch. If you're planning to have both an API and a Web site accessing the same data, consider using one framework for both as it helps prevent duplicating logic. CakePHP and Yii are good examples of multipurpose frameworks that are suited for this type of development.
If Python is an option, it is trivial to use a light-weight http framework to build a REST API that accesses a database.
Here's a snippet for a fully functioning http server using the itty framework: https://github.com/toastdriven/itty/blob/master/examples/web_service.py and https://github.com/toastdriven/itty/blob/master/examples/posting_data.py
Look at this project which allows you to create an API REST in seconds.
https://github.com/GeekyTheory/Automatic-API-REST
Features
Creation a powerful API REST of your MySQL Data Base in Seconds.
Management of the API in situ, it is not neccesary an extra data base.
Private tables and fields.
Custom queries.
Installation
Clone the repo.
git clone https://github.com/GeekyTheory/Automatic-API-REST/
Place it in your web folder /var/www/YourWebPage/
Open the file config.php and complete all the fields with the server credencials.
Go to domain.com/AutomaticaApiRest
We have a game project designed on ASP&SQL Server, and we need to integrate it's user database with Drupal.
This would be easier from Project to Drupal (since there is user_save and user_delete functions available globally by using drupal bootstrap) but I'm not sure if we can execute PHP functions on an ASP platform.
Is there any documentation for this kind of problems? What do you suggest?
First of all, I think you should rethink your strategy. Why did you choose ASP & MSSQL and why did you choose Drupal?
But if you really want to stick with it I guess by far the easiest way would be to write a PHP (SOAP) webservice that can be used to interact with Drupal (ie. add/delete users) using the Drupal API, and call this from your ASP code.
****edit****
You could use the SOAP Server and Services modules of Drupal. Or just write a plain and simple webservice from scratch using the PHP soap classes.
If you're just looking to use the games user database for authentication I know Drupal has a few modules that allow for authentication via external services. I believe basic or digest HTTP is pretty straightforward but it probably wouldn't be too difficult to write a services layer on the ASP app. Check out Drupal's "user access/authentication" section for ideas on external authentication.
you can build your own drupal module and build an api that exposes everything you want to do, im pretty sure asp.net has a lib or something should be out there to build a simple xml-rpc, rest client, avoid soap, you will add an extra layer that you dont really need