wso2 stream processor i am using as a complex event processing engine. So, I want to integrate this with front-end application so that dynamic querying can be made. I want only query and retention period(if exists) to be change dynamically using front-end application. How can we achieve this.
You can use Stream Processor app management REST API to deploy/undeploy apps. You FE application can make REST calls hand handle dynamic deployment.
Related
I am currently running WSO2 Analytics on a windows server but I want implement the analysing part somehow that a client can connect to the server and do some processing like visualization on its own rather than all processing being done on the server. Is this something possible on WSO2 platform?
Thanks
You can setup database you want ( see the documentation ). For production usage I woudn't even recomment using the bundled H2 database. WSO2 analytics supports number of databases by default, I believe Oracle is one of them.
As stated in the comments - you can create a client or service which reads the data from the database and displays them its own way.
most challenging part for me is that how the client uses the information from the database?
This is already on your own (outside scope of this question). You've asked if your client can access the analytics (result) data - yes you can. How to do that is up to you. (depending what the client is, ..)
For example at our client they are building data APIs which are directly consumable by different frontend libraries creating nicer charts and reports.
Apologies as I am new to the webservice space. I would like to ask some guidance on how to create a webservice that will receive data from a mobile app (XML or JSON). It will just be a simple call and Inwould need the data to be inserted to our database. I can manage to deal with the DB and the actual flow and my issue is more on how to create the actual webservice from Mule. and thought examples and comment will be appreciated.
Thanks Again
Creating web-services in Mule is pretty easy to implement and start consuming.
You can go through these links to give you a good headstart:
https://docs.mulesoft.com/mule-user-guide/v/3.7/building-web-services-with-cxf
And you can play with this project:
https://github.com/marcotello/MuleESB/tree/master/simplecxfservice
However, as you mention you know something about the mule components and flows, you'll have to do transformation of your XML/JSON input received from the mobile App to be able to be saved in Database properly.
To accept requests from mobile applications - create light weight rest APIs that consume JSON payload over the http protocol.
There are various frameworks to create rest APIs. To develop rest APIs using mule follow:
https://docs.mulesoft.com/mule-user-guide/v/3.7/rest-api-examples
Once you create a rest API, use a JSON-Object transformer with a return type of java.util.map to access each of the fields in the JSON payload.
Check out the available transformers at the below mentioned link.
https://docs.mulesoft.com/mule-user-guide/v/3.7/transformers
I have a requirement to build a service endpoint to provide specific Sitecore 8.0 items (containing a given field value in a given branch of the content tree) to requesting mobile app clients. Encapsulating this logic (and perhaps some other calculations, etc) means the out-of-the-box API is not suitable.
I'd like to mimic an existing SOAP service exposed by another CMS, however I'm not above using a modified version of the RESTful itemWebApi if it confers greater code reusability or upgrade-safety.
Based on my research thusfar, it would appear my options are to build a custom handler, a completely separate asmx service (ala this approach), or to build a custom controller (similar to this custom Web API controller method).
Overriding or replacing the default pipeline processors for the itemWebApi does not seem viable, as I don't want to replace/modify the OOB API if I can avoid it.
Has anyone with the same type of requirement for Sitecore 8 found a better approach?
The approach I chose was to create a separate service "router" developed using the adapter pattern to be consumed by our mobile app clients. The router in turn calls the Sitecore ItemWebApi.
This fit my needs the best as it is completely decoupled from the Sitecore application and the client can be modified if necessary without impacting the endpoint.
It would also be worth looking to EntityService within Sitecore.Services.Client in Sitecore 8. Its a Web API based service but has more flexibility over the standard Sitecore Item Web API because you can define your model and the business logic yourself.
I can see you have mention my other blog post on adding a custom Web API controller. Enitity Service is different, it's a framework by Sitecore to achieve a standard way of creating custom web service for Sitecore.
I have written a blog post on EntityService. It has both a Javascript and standard rest based API to communicate with the service too.
http://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Example Application here: https://github.com/sobek1985/EntityServiceDemo
And a few more posts on advanced features in Entity Service: http://mikerobbins.co.uk/category/sitecore/sitecore-service-client/
I am trying to build a mobile application on which a user could buy products from the application, I want to know if would be advisable to fetch data from web service or store it locally like in a plist file in case of IOS.
If i fetch data using a web service would it affect the performance?
Or what is the best way in which i can implement a web service in IOS.
Advice on this would be highly appreciated.
A commerce app typically has components such as catalog, cart, checkout and payments. Since you're talking about a mobile shopping app, I'd recommend you to use Core data for your Catalog because there are very less chances of products and categories being modified and that's the section of the app that's accessed most frequently. It'll make the app load faster and you'll have to make fewer network calls which in turn improves the performance of your app. You can fetch Catalog data once a day from your server or whatever time sounds more reasonable to you but fetching and updating cart, making payment, checkout etc. must be handled on server side for which you'll be required to use a Web Service, every time they're accessed.
A friend wants to consume my ASP.NET MVC 2 application in a similar fashion as adding a web reference to it, accessing my functions, and using my model objects from a .Net web form from a separate website.
Any links out there that could explain how to "dress" my MVC responses so that his server to server consumption would be similar in experience to a web service?
I suggested using System.Net.WebClient to pull the results in to a variable then deserialize the JSON result, but maybe there's a better approach out there?
I'd suggest that you consider an API controller or a separate API application depending on the load you expect from people consuming data from your application. A separate API application will allow you to move it off your application servers if needed.
Rarely, will you find that the data that you would provide via an API is a one-to-one match with what your views need to be rendered. Behind the scenes you could abstract the data generation so that your API and your application controllers reuse the same code to get at the data, but the front-end of the API would understand how to negotiate security (from an API perspective) and present data that is easily consumed by a program. Moreover, you won't find that you're creating extra controllers and methods in your application just to provide some data that will never be used in a particular view.
You could use MVC or WCF for the API and JSON or XML as the payload format. If you use WCF, you get the benefit that he really can simply add a service reference to connect to it without you having to build a WSDL file/action.
From another's advice, Phil Haack added this to MVC 2 Futures. Add the DLL reference to the Application Start, and bingo. It uses a validator.