I have a requirement for getting a CRM URL via a custom workflow to use in the next step which is to send an email. The reason for this is to differentiate to users which server this email has come from (UAT/Live).
I have been trying to use HTTPContext route as advised from this site https://social.microsoft.com/Forums/en-US/31ff567d-65ea-4385-a764-68a2121ae8c0/ms-crm-2011-get-path-of-crm-server-url-in-plugin?forum=crmdevelopment but the result I get back is useless as I am I am only receiving an "/" back.
Does anyone know what to do from this point or why this may not be working?
This can't be accomplished, in a supported manner, without creating a connection to the CRM Discovery Service, which requires that you supply credentials. The organization service, available in the workflow does not have a method for discovering the organization's URL.
You have two options:
1) Pass it to the workflow as a parameter using the InputParameter code attribute on your CodeActivity.
2) Create (if you don't already have one) a configuration entity to store the URL and retrieve it in your code.
If you don't really need the URL (i.e., you are not creating a link) then you could just query the Organization entity for the Name attribute. That will give you the Organization's name - which would be the only unique part of the URL. This would allow you to indicate to the user if the Email was coming from UAT or Prod.
I ended up coming up with a solution by using the environment.machinename to pull through the server name. From there i could determine which production server the workflow had been run through and passed a string containing, dev, uat or live to the output to use in my activity emails.
Be aware i had to register the workflow without it being in sandbox mode. Hope this helps somebody in the future.
This was an extremely old question but I came across it while attempting to do something similar.
I found that there is a RetrieveCurrentOrganizationRequest request which was introduced in v9. This will work in sandboxed plugins.
You can use this to retrieve the endpoint urls like so
var currentOrg = base.OrgService.Execute(
new RetrieveCurrentOrganizationRequest()
) as RetrieveCurrentOrganizationResponse;
var url = currentOrg.Detail.Endpoints
.Where(e => e.Key == EndpointType.WebApplication)
.FirstOrDefault()
.Value;
More information here: RetrieveCurrentOrganizationRequest
When I used it, I found that there are 3 available URLs in the Endpoints collection:
Web Application
Organization Data Service
Organization Service
Relevant to CRM 2013 (which the OP was using at the time), there is also the RetrieveOrganizationRequest class which does the same as above; however you have to specify the Organization (and some other information)
Related
I have to consume some service on ESB which has addresses:
for dev env: http://esbdev.com:11111/ws/ir.channel.aaa.pub.ws:ConsumeMeV1
for test env: https://esbtest.com:22222/ws/ir.channel.aaa.ws:DoAmazingCalc
Functionality is the same.
Can I somehow have only one common code (to rule them all) in c# generated from WSDL and manipulate to which env I’m connecting by some config?
And can i switch freely between http on dev and https on test environment?
Now I’m calling it on dev like:
using (ConsumeMeV1_PortTypeClient client = new ConsumeMeV1_PortTypeClient(this.EsbEndpointBinding, this.EsbEndpointAddress))
But there is dev name hardcoded - how should i map ConsumeMeV1 to DoAmazingCalc on test?
On test I'm calling it like:
using (DoAmazingCalc_PortTypeClient client = new DoAmazingCalc_PortTypeClient(this.EsbEndpointBinding, this.EsbEndpointAddress))
Can I generate common clases like:
using (BestServiceNameClient client = new BestServiceNameClient(this.EsbEndpointBinding, this.EsbEndpointAddress))
The best option for me is to get endpoint/names config from database and inject to clinet class - but how?
Ok, I know where the minuses come from.
No part of the address matters as long as the functionality underneath it does not change. So both generated classes will allow you to use them with each of the given addresses. I note that these obvious things are like that only when you know about it, so I'm sorry that no one even wrote a word about it.
However, when it comes to https, it depends on the BasicHttpBinding.Security.Mode settings. You can set Transport for https and TransportCredentialOnly for http. The corresponding value can be saved and retrieved from the database or other configuration together with the user and password.
I use the above with the setting:
BasicHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
I am expanding my website to another country.
It's basically a listing of events.
I'd like to only show events from belgium if domain is {companyname}.be, only events from the netherlands if {companyname}.nl etc.
To keep the costs down I want this to work in a single azure web app, so I'd need to get the domain name from the request since I cannot set this in configuration.
I know i can get the current domain by using
HttpContext.Current.Request.Url.Host
But I feel I'm missing some "best practice" approach. Something that would also work in development and preproduction environments.. any documentation you know of that could help me out?
UPDATE
I have mapped multiple custom domains to my web app. It works well, the result as below.
PRIVIOUS
we also can use second-level domain names to fulfill your needs. You can use be.websitename.com to access on behalf of Belgian users.
//Home/getUrl
public IActionResult getUrl() {
string url = HttpContext.Request.Host.Value;
return Content(url);
}
You can set your second-level domain in your portal. Like pic.
Then you can test it by broswer.
I maintain an ASP.NET Web API project which supports a simple REST end point for clients to post XML data to our server. This site is setup to support BasicAuthentication and works very well. All of our security checks are done at the network firewall and on the machine itself using custom Windows User accounts. Recently, one of our clients requires that we support a SOAP end point to receive the XML data as well.
My thought was to simply add a new WebService (Blah.svc) with supporting interface having the required [ServiceContract] and [OperationContract] attributes to my interface. I had hoped that I could simply expose the URL to our client and it would "just work". I am able to hit the end point, but this service is not able to extract the user name.
Here is my sample code:
public string CreateWorkItem(string xml)
{
var userName = HttpContext.Current.User.Identity.Name;
if (string.IsNullOrEmpty(userName))
userName = "NO USER NAME";
var elem = XElement.Parse(xml);
return $"Hello [{userName}]! You sent [{elem.Value}].";
}
Here are my results:
I've scoured the web to try and find out how to get access to the BasicAuthentication details in a Soap message, but I'm not having any luck. All the examples that I'm finding require that I create a new WCF project and expose it with a lot of web.config settings, or the examples are ~5 years old using older techniques.
I'd like this service to simply publish with my WebAPI project using the Publish... option inside Visual Studio. Unfortunately, I've not found a common denominator to make it work. I'm sure I'm missing something, and I hope someone can help.
Any help would be greatly appreciated!
Check this link out: WCF Services and ASP.NET
In short you need to enable ASP.NET Compatibility in your WCF service.
However, you may want to look into using OperationContext.Current.ServiceSecurityContext.*
The fact that it is HttpContext.Current.User.Identity.Name is returning null means either:
User is null; or
User is Anonymous
I have a few ideas to help resolve the issue.
1. Your User.Name is actually null
You might want to debug by grabbing HttpContext.Current.User and see if it's correct.
2. Go direct: get the cookie via a parameter
Try and pass the HttpContext as a parameter so you can grab the cookie?
public string CreateWorkItem(HttpContext context, string xml)
{
var username = context.Current.User.Identity.Name;
...
}
3. Your configurations are not setup properly
The alternative is that maybe your web.config or Global.asax is not setup to properly.
I'm attempting to get a list of all Recurring Payment plans using the C# API. The result is always NULL. What am I doing wrong? I setup and tested other similar API requests such as Invoie.GetAll and that works, so I am confident my user account is setup correctly, I have a good auth token, etc.
Here is my code (note: I've tried passing the optional parameters too with no luck). Perhaps there is a bug with the Api?
var plans = PayPal.Api.Plan.List(_apiContext);
return Xml(plans);
Turns out I needed to use Express Checkout of the NVP and SOAP API Reference. I have something working now.
Is there a way to get the root url of the current server the Share Point application is hosted on? For example, if I want to load information from a site I'm currently typing:
SPSite site = new SPSite(http://dev3);
But when I move the development code onto the production server I have to manually replace the site URLs with the new server URLs:
SPSite site = new SPSite(http://sp2010);
I'm using C# in Visual Studio 2010.
I am not sure if I understood your context correctly, but you should be able to use SPContext property.
SPContext.Current.Site.Url;
If you want to get the hostname of the current machine, it's this:
System.Net.Dns.GetHostName()
If you're looking for something using the SharePoint Object Model, try this:
new SPSite(SPServer.Local.Address.ToString())
So the problem that you are facing is that the code has to adjust to the different urls in different environments?
There are two ways to handle this
Ensure that the Urls are the same in all the environments by using a host header in IIS This would result in the urls being the same in both the DEV machine and the PROD machine. (On the DEV machine you would also need to set up the BackConnectionHostNames in registry for it to work well, because you would be logging in to the DEV box and working locally from there).
[1] http://www.it-notebook.org/iis/article/understanding_host_headers.htm
[2] http://support.microsoft.com/kb/896861
But a more standard (and realistic) way of solving this would be to keep the root site name in a config file and let the code pick it up from there. For different environments, you just need to go and update the config file. You can also automate this by seting up your installer to replace the strings based on the environment to which it is getting installed to. The advantage that you get is that you are not hard-coding the Url, and the logic is not dependent on the hostname of the server (There would definitely be scenarios where a host header is used, or an alternate access mapping resulting in the url being different from the host name of your sever). So this way you get better de-coupling.
Just my two cents.
For me, these hints didn't work out. I have several site collections and instead of using DNS information I found it safer to get the url of the topmost site collection of the web application like this:
[current SPWeb].Site.WebApplication.AlternateUrls[0].IncomingUrl
or (longer and resulting in an URL with trailing slash):
[current SPWeb].Site.WebApplication.AlternateUrls[0].Uri.AbsoluteUri
If you want to get all of the web applications on a machine you can get this collection:
Microsoft.SharePoint.Administration.SPWebService.ContentService.WebApplications
For good measure, here is how you get the administrative web application(s):
Microsoft.SharePoint.Administration.SPWebService.AdministrationService.WebApplications
By using these approaches you can go a long way towards hard coding site collection urls into your code base.
Careful!
Although the first item in the WebApplication.Sites collection is usually the root site collection, it is not guaranteed to be item zero [0] if you happen to delete and recreate the root site collection after other site collections have been created. A more reliable way is to reference the site collection using the root URL like this.
WebApplication.Sites["/"]
Also, SharePoint timer jobs execute within the context of the web application. So, for a timer job:
using (SPSite site = this.WebApplication.Sites["/"])
{
}
This will take you to the home page in whatever site or subsite you are in. Rather than the root site home page.
SPContext.Current.Web.Url;