Created an account site for an account through in oracle e-Business Suite screen.
Wrote a service to update this account site from other third party application. So calling API update_cust_acct_site from C# to update the account site details. It called the API and updated the detail well in ebs table. I can query it in oracle table through sql developer. But I could not see the account, account site in oracle e-Business Suite application screen.
In this way, I am also updating Location, party site and customer sit use objects using the API.
Why i could not see it in e-Business Suite after calling the API?
Should I need to run anything else to make it visible in application?
please help me.
I am not good in Oracle / EBS stuffs.
thanks
Related
I am working on a ASP.NET (Blazor) server which is connected to Azure. The user management works perfectly fine and the data gets written and read to/from Azure. Anyway, I just started to work on user roles.
My first approach was to have a table in the database which contains all my users and I store my custom roles there as well. But with this approach I cannot use the Identity Platform to its fullest.
The second idea was that I use the role management directly from Azure AD. This would give me the possibility to use the Identity Platform better. But in our tool we need to manage the users and roles. Therefore, I need user roles to be updated in our app and then synced with Azure AD.
I searched around regarding this but did not find any solution regarding this. Maybe my approach is completely wrong from the get-go and someone has a completely different idea.
Usually in the Blazor Server projects where I use the Microsoft Identity Platform I use the Azure RBAC (Azure role-based access control).
You can manage the roles using the Azure Portal or the Azure Graph API, you can check Microsoft's documentation for this one too at Add app roles to your application and receive them in the token.
Has anyone implemented a project using Azure for user registration and authentication?
I can see how it would work well in an Enterprise application, but it seems as if there is no easy way to enable "self registration"
It looks like it is intended to work with an on premises AD solution, or alternatively for new users to be added using the Azure management portal.
Can anyone give me the benefit of their experience?
WAAD is a fully implemented solution for what I think you are trying to do, but created in a way very different than the "Active Directory" server product that it shares a name with. Take a look at the Windows Azure Active Directory Graph API, which is the RESTful management API for WAAD. With Graph API you would be able to create a fully functional application authenication system to meet your needs.
Overview
http://msdn.microsoft.com/en-us/library/windowsazure/hh974482.aspx
API Reference
http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx
Links, Examples, etc
http://msdn.microsoft.com/en-us/library/windowsazure/hh974476.aspx
I know such questions have already been asked many times, but I am here with my scenario. Kindly do not delete or vote to close.
I have an asp.net application with L2S and SQL 2008 R2 as backend
Using N-Layered architectured
Mostly normal crud operations to be performed.
Use of Sessions and View States
Manual Login / Logout(User and Roles management) , no .net Membership has been used.
No services used yet, might be a later part.
Third Party controls like Telerik or Infragistics also are in use.
I want to know:
Do i need to change entire application to Azure Web Application?
If not, is it possible to deploy it directly over the cloud , on MS or any other, as we normally do in IIS?
If not, Is there any third party migration tool available to make my plain old web application cloud-compatible, without affecting existing codes ?
I want cost effective and easy to go steps?
Thanks in advance
Yes that should be possible. You almost certainly do NOT have to change your whole application.
Linq2SQL is fine, I run an Azure site with L2S without any problems
You'll have to deploy your DB to a SQL Azure database. There are some restrictions, like all of your tables must have a primary key. A bigger list is here: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx.
Also, when generating your SQL scripts, be sure to select SQL Azure as the database engine type: http://mooneyblog.mmdbsolutions.com/index.php/2011/09/22/generating-azure-friendly-sql-scripts/
What do your N-layers look like? If they are DLLs, it's fine. If they are web services, you'll need to create web roles for them. If they are windows services, you'll need to port them to a worker role.
Most crud and view state and manual authentication code is fine
For session, it depends on what you are doing (memory vs database). But you'll have the same challenges that you would have if you deployed to any web farm
For Telerik, I'm sure they have to have some support for Azure, and I don't think they would be doing anything crazy that would not work Azure. You should check out their website to verify compatibility.
Also, make sure you are not writing to the hard drive anywhere and expecting it to be there later, because instances can be started and stopped and reimaged at any point. If you're doing that, you'll need to change it to use something else like blob storage.
I have an ongoing series of blog posts that walk through some of the steps, which should help: http://mooneyblog.mmdbsolutions.com/index.php/category/azure/
Good luck!
I don't see any hassles to deploy your web application into the cloud.
You don't need to convert your entire application to anything else.
After all you can just try to deploy it now with the trial subscription in Windows Azure which is free for three months.
There is a fairly big stuff of new technology in Windows Azure such as service bus, azure storage, access control service, etc. However it's not necessary to use all them right now. It's prety easy just to move the existing app into the cloud.
You can deploy it to Azure web site.
That should be easier if you don't want to use SQL Azure and cloud storage.
We have many custom built web applications (both external & internal) written in Classic ASP and ASP.NET 2.0 technologies. Internal users can upload files to these websites, which can then be viewed by External Users. In some cases, external users can upload documents as well.
Screenshot #1 gives a brief idea about the existing architecture.
Internal users upload documents to custom web applications. These documents are stored in a folder structure defined under the web application.
Meta data and user permissions like who can access the documents are stored in SQL Server database.
The same set of documents that are being uploaded to custom web applications also exist in SharePoint. However, the custom web applications are unaware of SharePoint. So, users have to download them from SharePoint and then Upload it to the custom web applications. We are currently using SharePoint 2010.
External users can also upload documents to the custom web applications. The meta data and user permissions of the document are saved into database based on the user who is uploading the document.
Screenshot #1:
Screenshot #2 shows the architecture that I am trying to achieve. I have done very little SharePoint development. Mostly, I have used the SharePoint web services to retrieve some list content but nothing more than that. Our future Custom Web Applications might be written using ASP.NET MVC. Please find the questions after the screenshot.
Screenshot #2:
Here are my questions:
I would like to have internal users continue to upload and maintain their documents in SharePoint. User security model is already defined in the SQL Server database. This security permissions should be available in the SharePoint document properties so users can choose who can view the document from the custom web applications. How can I achieve this? Should I have to copy the SQL Server user permissions info to SharePoint?
I believe that SharePoint Web Services or Business Connectivity Services (BCS) can help in retrieving the document and its related info from SharePoint. Which one of these would better suit this scenario?
Custom web app should display only the committed versions of the documents. If a user has checked out a document in SharePoint to make any changes, that checked out version of the document should not be visible to External users. Is that possible?
Has anyone tried this approach? Are there any pitfalls with this model? Are there any performance concerns with this design?
Will this design be of any hindrance if I rewrite our existing applications using ASP.NET MVC?
Is it possible to make use of SharePoint search feature within the custom web application (ASP.NET Web Forms / ASP.NET MVC)? In other words, can I send search criteria from custom web app and have SharePoint do the search and return the results back to custom web app?
I really appreciate your inputs.
Thanks in advance.
Question 1
Hard to say without having more details. So I'm going to assume that you currently use Active Directory for your authentication store. So this means that your SQL Server defines a list of roles and then has assigned memberships to these roles. I'm going to assume that your assigned membership is to AD users or groups. If this is true then I think your on the right path to push your permissions from SQL Server into SharePoint. SharePoint's API will accommodate what you need to do, however SharePoint has no built into mechanism for syncing your permission changes so that means you end up writing a whole lot of plumbing code. I would recommend that you research products that can handle the synchronization for you. Microsoft MIIS (I believe it is called Forefront Identity Management now) offer a set of architecture patterns that you should investigate.
Question 2
SharePoint Web Services or the SharePoint Client Access Services should work fine. I would highly recommend that use a proxy pattern to isolate your application from SharePoint calls (so you can isolate your application from SharePoint upgrades and potential content management server changes).
Question 3
Yes, that is possible. If you are using the publishing features of SharePoint Server (NOT SharePoint Foundation) you will have an easy way of identifying the current published version. Otherwise the service account you query with should be setup so it can only read published versions then SharePoint will automatically trim your query.
Question 4
I have not personally tried this design, but I really like the concept of creating a content management domain and then putting an abstract service layer on top of it. Will you have scale problems, depends on how you configure SharePoint and your applications. You can do it right or wrong. An depth answer between the two cannot be covered here. My one piece of advice is to make sure you plan for caching in your service interfaces (cache, cache, cache).
Question 5
Not if you implement it as a Service Layer. You would just use a repository pattern to call the service and return back entities for your model.
Question 6
Yes, Search is exposed via an API so it can be wrapped in a service layer too.
Good luck and feel free to contact me directly for more in depth discussion.
i have published my website...its a dynamic site..so i have database connectivity..now i want to make an application in VB to update my database using my application..i mean i do not want to login to the site and update my database rather update it using my application..i want to connect my application to the database of the published site and update it from anywhere i want using the application...is it possible??
How can i do it??Please point me to the right direction...its urgent.
you can turn on AllowRemoteConnections in your SQLServer. so your application from any where can connect to it and update the DB.
but the best practice for this is using a WCF Service. You should place your methods for updating the DB in a WCF Service farm and then write a client application using Windows Forms or WPF to connect to WCF Service and update the DB using Provided methods in WCF Service.
Although what you want to do is possible you probably don't want to do that. If you are hosting your site with an ISP the hosting company will need to provide the access.
However, as Farzin suggests, you need an integration layer between your application and the database.
You could go with a WCF Service but if it is something simple you could even expose your data using something like MVC.
All you basically need is the security wrapped around your database.
Have you taken a look at Lightswitch? It is currently Beta2 but still quite robust. Using Lightswitch you can quickly set up an app which performs CRUD operations on your database.