I have stored my database on a server say abc.xyz.com
I want to use one of database from this server for azure mobile service.
How can I access this database from my mobile service.?
If you're using the .NET backend of your mobile service, you can fairly easily use the external DB - since it uses Entity Framework as the default data access platform, you can use its tools to create the connection to your DB.
First, open the Entity Framework wizard to "Generate Model from Existing Database": right-click the project, select Add --> New Item --> ADO.NET Entity Data Model, and choose one of the options with from an existing DB (either "EF Designer from database" or "Code First from database"). The wizard will create a context class which you can use when implementing your tables.
Notice that you may need to implement some data mapping since to expose data in the TableController<T> classes you need the T parameter to implement the ITableData interface. The post at http://blogs.msdn.com/b/azuremobile/archive/2014/05/27/bring-your-own-database-with-the-net-backend.aspx and the tutorial at http://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-use-existing-sql-database/ have more information on how to implement your scenario.
Related
Is it possible to create liferay service builder without any configuring any database tables in service.xml file.
Actually purpose here is to create a service layer using liferay service builder. And there is no database interaction directly in this service layer.
Yes, and it's quite simple. While you still need an entity (which provides the name for your service) you can leave this entity definition empty.
This will create the service (local or remote, as configured in the entity) but no model, no persistence and no database table.
One of the situations where this comes in really handy is when you want to add another method to an existing service (which you can't) - you just create a new service with your custom methods and delegate to the original service.
I agree with #Olaf Kock answare in which say that it is possible have an empty model with service builder. Furthermore have an empty entity you can benefit of have the same transactional context of your portal and benefit of cluster managing and benefit of a complete integration with liferay portal.
If you have the same transactional enviroment of the portal you can image of create a service that agregate native liferay service and you get the assurance that the transactional context is the same of the portal.
I hop that this reflection can add value.
Its highly recommended that If you're creating Service.xml then at least one entity should be there. Otherwise no need to add that configuration.
Able to create service builder without real entities.
As provided in the link it is possible to create service builder without entities.
Also discussed more in detail in this forum
Hope it helps some one. Thanks
I have created Azure Mobile Service using Azure portal and selected a existing database.
Now I have few questions:
Whenever I'll run the application, database gets cleared as ClearDatabaseSchemaIfModelChanges has configured for Database Initializer in WebApiConfig. Can I use database first approach for Entity Framework?
My existing database has default schema is dbo but it will create a new schema for all tables same as service name. How to overcome this scenario?
Finally, TableController is tightly bind to a table. But output requires in my case is bit complex as I require data from multiple table using join each other. And I also wants to add some logic before giving return the result.
And a tightly bound table also requires some common columns like CreatedAt, UpdatedAt, Id, Deleted as it inherit from EntityData class. But In my existing tables, columns are not there.
Help me out !!
You can do the following:
1) Create the custom API for your operations (that are not so tightly connected with the HTTP verbs and the table)
2) Manipulate the DB manually - it is just a SQL Azure database that can be managed by SQL Servre Management Studio, Visual Studio or queries.
So, shortly, if you need the flexibility of doing what you need with the database, you can do it, but Mobile Services is a service, so there are some limitations.
Hope that helps. If not, please elaborate the issue.
first, you should be using Azure Mobile Apps instead of Azure Mobile Services.
You can follow what Alexandr has mentioned, or you can stick with using Mobile App by extending your existing tables to add the required columns (especially if you want to do sync).
The TableControllers are just plain WebAPI controllers, you can certainly extend it.
Have a look at this link for a more guided step on how reuse an existing database.
I want to create a project in Asp.Net MVC with C# using Entity Framework with BAL and DAL layers ? There are two module here User and Admin module with custom login feature. Admin can add run time columns in the existing database with add, edit update the records such as any report.
The record display to the users.
If you have any such type of reference article/project (N-tier architecture) let us know please.
When i create MVC projects, i usually follow this structure:
UI Layer - This will be the actual mvc project and will interact with the service layer
Service Layer (BAL) - This will hold all your business logic classes and will interact with the data access layer. This layer will expose services the UI Layer can make use of
Data Access Layer - This will hold all classes related to data access. As you are using entity framework, your DbContext can live here
Entities - This will hold all entities used in your solution
I have added some tables to my database in in windows azure via entity framework however I am not able to access these tables through the server side scripts (mobile services custom api)and they do not appear through the "MOBILE SERVICES: DATA" section. Do I have to add these tables and set permissions on them manually though the portal to get access to these via the scripts etc? I am sure there is some documentation on this somewhere but have been chasing my tail trying to find it.
The only table that currently appears there is the TodoItem table created by default.
A bit of direct on this would be great
you need to move it to the schema of your Mobile Services App and add the tables, see: http://blogs.msdn.com/b/jpsanders/archive/2013/05/24/using-an-existing-azure-sql-table-with-windows-azure-mobile-services.aspx
You only need to define the table name through the portal interface, its pretty easy to use. This is also when you define if that table requires authentication, and which kind of authentication you will use, also pretty well explained in the interface so I will leave that to you. After you've done this basic layout in azure, the entity framework will take over and define the table details from within your code. (Version and table type Depending) Something like;
private IMobileServiceSyncTable<MyTable> mySyncTable = App.MobileService.GetSyncTable<MyTable>();
Your table names in azure must exactly match the class names that your using in the code to define the tables, this mirroring is how the server maps your data to its intended location in the cloud.
You should now have complete access to your cloud data from the MobileServices API by calling operations on mySyncTable.
How should data be pushed into CRM 2011 from another system?
I would like to pass the data to a web service.
I have thought of 2 options so far:
Create a custom entity and create records of this entity by calling the Organization service from the other system. A workflow can handle everything from that point.
Create a WCF service and host it somewhere. The other system passes data to this service and the service interacts with CRM.
The client will just pass us records, so validation must happen on the CRM side.
EDIT:
If the client is an old system (in Cobol or something) is it still possible to connect to the CRM service?
Just to expand on Predro's answer:
I have actually done both with CRM 4. I would highly reccommend that you create your own sevice for the client to call which in turn calls the CRM services.
This gives you an extra layer of abstraction for when things change later - and they will.
If your client calls the CRM services directly it will be difficult/impossible for you to change your internal data structures or move servers around in the farm. Esecially true if you currently use a singer-server infrastructre.
Also don't map the service you create directly to the entity data structure, use an intermidiate model.
So if you wanted the client to pass Account details in, have your service expect an XML document that you convert in to an Account Entity, rather than expose the Account Entity and have your client submit that.
The second choice for me is the best way to handle with this situation, because you can control and validate everything in your side. You can host the WCF service in the same server of CRM Dynamics or in another server with access to CRM Dynamics and interact with with CRM through CRM Web Services.
I think you don't have any better solution.
Assuming the client has a login to your CRM system, I would actually go with the option #1 first. Why?
You can still validate the data in the Pre-Validation plugin stage.
This is by far the easiest and fastest way to get going. Will things change? Maybe! But:
You are going to spend lots and lots of hours getting a custom WCF service up and running
Somebody has to deploy it
Somebody has to maintain it
Your client has to learn how to connect to a proprietary WCF service instead of saying "Here's a bunch of published info on how to connect to CRM's webservices."
It becomes a "hidden silo" of business logic instead of it all existing in CRM. Any good CRM developer would be able to work on option number one. Number two requires additional skills.
If it really does change over time so much that it needs its own WCF service, you haven't really wasted that much time. All your business logic would be ported from a plugin to the WCF service. But it is much harder to go from the more complex solution (#2) to the simpler solution (#1) if it turns out that you don't need it.
I promise you that your customer wants this done faster and simpler (cheaper) rather than longer and more complex (expensive).