I am new in AX.
My boss gave me to task to access tables of AX 2012 from C#.
Following are the criteria:
Code should be generic. (user will give me table name, column name
and any condition if there, to execute insert, delete, update or
select queries).
Client and server may be or may not be in same
Client and server may be or may not be in same
domain Without any installation on client machine
I tried Business connector. But, we can't use business connector outside the domain and it requires installation on client machine
I tried web service. But, We need to add service reference for each web service group.
Is there any thing best suitable for my requirement? Or am I missing something while using above two ways?
Please help to resolve this issue. I am doing this since last month.
You can use AifGenericDocumentService. The wsdl is available by default at http://_AOS_:_8101_/DynamicsAx/Services/AifGDS?singleWsdl.
This is a generic web service, so if you don't know the schema for target tables you can also use MetadataService at http://_AOS_:_8101_/DynamicsAx/Services/MetadataService?singleWsdl
You can see an example at https://community.dynamics.com/ax/b/microsoftdynamicsaxintegration/archive/2012/05/06/microsoft-dynamics-ax-2012-application-integration-framework-custom-web-service-loosely-typed
Related
I am authoring an installer that creates a new website and application pool. This installer is for internal use within several development environments which all have subtle differences. One may use only HTTP, another only HTTPS and one might use both. One might use the default ApplicationPoolIdentity identity where as another may use an explicit User reference.
Given the association of a WebAppPool is by ID through a WebApplication which must be nested under a WebSite, each time an option is desired on the installer, the breakout and duplication of features gets ridiculous.
I imagine I am not the first to encounter this, how does one accomplish this much flexibility within an installer?
The route I went with was creating a basic template within WIX using expected IDs, then used an immediate custom action scheduled before InstallValidate which manipulated the template entries to what ever degree was required. The properties used by the CA to make the decisions are stored in the registry for modify/patch/removal invocations.
I have been trying to find a standard way to include databases schema patches into my Azure continuous deployment flow.
So the problem I am looking for a solution to, is that as an application evolves, so does the database. Ever so often there are changes to the database to support new functionality etc.
In earlier work situations I have used proprietary solutions that hold changes to the database in a linked list in an Xml document. The database then knows the latest patch it applied, and if any new patches are present it will apply them. That way it is easy to keep all environments synchronised, and the changes follow the code.
While these proprietary solutions have worked great, I was thinking that before I implement yet another tool to do this, I would see if there was a standard solution provided by SQL Azure to solve this problem. But I haven't been able to find one.
Is there one or do I need to create a tool myself?
Visual Studio Database Projects support deploying to Azure SQL Database so this is a good way to incorporate it into a CI workflow. If you are used to traditional deployment methods it is a bit of a mindset change; these projects work out at deploy-time what to deploy. For example, if you want to create a table, add a Table to the project and fill out the columns. Then, say months later, you want to add a column, simply add the column to the CREATE TABLE script. When you deploy, it will work out that the only schema change is a new column and it will add it.
This is a nice little series on that topic:
https://channel9.msdn.com/Blogs/Have-you-tried-turning-it-off-and-on-again/Creating-a-Database-Project-for-Artificial-Intelligence
i am building a ticketing system which customers can add new tickets to the system and employees can help them with there requests. I built the data base with an ADO file and my question is, is it possible to use the identity user and all of the database that comes with the mvc5 web application yet add additional tables with connections. i have been trying to do this for a while with no success.
!(http://postimg.org/image/v49eh3gql/) this is my database and i would like to extend application user and use my other attributes as well as my other tables and the roles table that comes with mvc all in one database.
any help would be appreciated
cheers :)
You could use the same database but I think its better to keep them apart. Add the properties for your user entity to IdentityModels.Cs and to the AccountViewModels.cs where appropriate. Since the views for these viewmodels are already created you have to add the attributes to the view yourself. Then in the package manager console Enable-Migrations Copy and paste the command that has the applicationDbConted in it. Add-Migration -Init then run Update-Database
Here is a post about how to access the logged in user.
is it possible to use the identity user and all of the database that comes with the mvc5 web application yet add additional tables with connections.
In other words, can you have an application with database first and model first?
Yes, but you have to be careful that you don't migrate the database first dbcontext.
I don't know about SharePoint that much, so hope that someone can give me some good explanations for me.
For SharePoint application, we don't need to consider SharePoint DB design? Everything is done through List and SharePoint will take care of the Database? Don't need to consider it at all unless we are connecting to the external Database?
For Parent Child relationship, I have to use lookup field?
If we are developing using Web parts, we need to deploy it using Features. So eventually, there can be so many features in the production? Is it recommended in this way?
1)
For SharePoint application, we don't need to consider SharePoint DB
design ? Everything is done through List and SharePoint will take care
of the Database ? Don't need to consider it at all unless we are
connecting to the external Database ?
You do need to consider the database... In term of administration. back ups, restore, size and so on.
however you never directly read or write to it. You don't need to pay attention to the schema because you won't ever be directly using it. If you want to update something in SharePoint you do it pragmatically with c# / vb.net using the SharePoint API's. You have 2 API's one that works on the server called the SharePoint object model and one that works on a remote machine called the client side object model.
From a users perspective, you are correct lists contain data in SharePoint and are somewhat smiler to DB tables in some ways.
2)
For Parent Child relationship, I have to use lookup field ?
Yip
3)
If we are developing using Web parts, we need to deploy it using
Features. So eventually, there can be so many features in the
production ? Is it recommended in this way?
This can happen if you create a new solution for every web part but you can bundle multiple web parts in the same solution in the same project in the same feature
Right click on your project --> add new item. select a web part. By default the web parts will all be part of the same feature but you can separate them out and have multiple features in the same solution if you want to
I'm in a machine that has already SharePoint installed, so when I started the SharePoint Central Administration to config, this message appear to me: "Can not connect to the database configuration."
How do I know which database is configured SharePoint?
Normally the Admin database is created using the naming convention SharePoint_AdminContent_{GUID}. However if there's more than one, you'll need to use SQL Management studo or other tool to look inside the DBs, look for a table called "DatabaseInformation" which will contain two items, look in the AlternateAccessMappingXML entry and look for the XML tage IncomingUrl, that should help you narrow it down.
Or just use the SQL profiler and watch for connections.
By default SharePoint will install the Database on the same machine as the web server, but you can ask whoever installed SharePoint on the machine.
Anyhow, most likely it's not relevant and something else is the problem, follow the resolution methods described here and you'll probably have it fixed.