I have written before how to call a Sage CRM .NET assembly from the user interface. The Developer Guide and existing blog articles discuss how we can call an assembly from a tab menu, a button group, a hyperlink from a grid and how an assembly can be invoked from a workflow. 

If we know how to link to a dll from the interface we should also know how do we can redirect the page back to the system. After all we may want to have the page carry out a process then not display its output like a summary page but rather once it has finished the work it is doing it should be returned to either the page that launced the dll or it should be redirected back to another page.

A typical example might be a dll that is called from a screen like OpportunitySummary by a workflow rule (perhaps a global rule). This workflow rule might create a file on the server, or do something else, but the page then just returns the use back to the OpportunitySummary page.

The target for redirection could be a system page (like the example workflow example above), another .NET assembly, or the same assembly but a different method or even to an ASP page.

If we are going to redirect then we will need to consider the target and context. The .NET API has a number of ways in which a URL can be built.

You can build a path to an existing system action using the Web.Url() method. When passed an action code it will return a correctly formatted URL that includes the current context information.

• Url("200")

Note: Knowing what codes can be used can be something of a mystery and I have been asked whether there is any documentation available for these actions. But the ability to call the CRM actions is not an official API, so can not be officially supported. In many instances however, it is useful that we can redirect to specific places in the CRM screens and it is easy enough to be able to read the 'Act' code with the screen URL.

For example the Company Summary screen has the 'Act' code of 200.

We can build the URL to call an ASP in a similar manner.

• Url("CustomPage.asp")

Calling a .NET assembly is more interesting. For example if we want to build a URL that points to a custom dll then we can use the Web.UrlDotNet() method. This accepts two parameters, the name of the target dll and the name of the method to be invoked. To build a path to the RelatedEntities list in a particular context we could use

• UrlDotNet("RelatedEntities", "RunREList")

But if we wanted to redirect back into are the dll currently being executed then the variable 'ThisDotNetDll' can be used. All we would have to do is pass the method name e.g.

• UrlDotNet(ThisDotNetDll, "RunMyMethod")

And yet if we wanted to call back to exactly the same method but to pass it different variables we can start to add our own 'flag' information to the URL. Consider this...

• UrlDotNet(ThisDotNetDll, ThisDotNetFunction)+" &myflag=myvalue"

The example above will build a URL that points to the same dll and the same method but will add a name/value pair into the QueryString. This could be looked for by the Dispatch.QueryField() method or the Dispatch.EitherField() method.

So far we have only considered how the target URL can be constructed and not how the redirect is caused.

You can then redirect from the .NET code using

• Dispatch.Redirect()

e.g.

• Dispatch.Redirect(Url("200"));

or

• Dispatch.Redirect(Url("CustomPage.asp")+" &myvariable=myvalue");