In MS Dynamics CRM how do we register a plugin or a workflow as part of a solution? whatever i register through registration tool, just goes to the root solution of the system.
Expanding on what #Henrik said, the process would be as follows.
For the sake of this example, let's assume you have a single assembly (dll) with two plugins and each needs two steps.
Register the assembly as usual with the Plugin Registration Tool.
For each of the two plugins, register the two steps they require. This should leave you with four in total.
Leave the Plugin Registration Tool and go to your solution in CRM. You will see two sections there: Plug-in Assemblies and Sdk Message Processing Steps.
You will need both of these to fully register a plugin with your solution.
Go to the Plug-in Assemblies section and use the Add Existing button. This will bring up a standard lookup dialogue that will let you select your assembly. Add it.
Next, go to the Sdk Message Processing Steps section and use the Add Existing button to add any plugin steps you want as part of the solution.
That's it. Your assembly, plugins, and steps are now part of the solution. Any step images that may exist are automatically added as part of the step so no need to worry about them.
One caveat though is that assemblies must be stored in the database and not as files for this to properly work. There is no specific limitation on sandboxed plugins (unless deploying to CRM Online) but using those would simplify solution deployment.
Finally, this walkthrough which was taken from the How To button in a solution.
Walkthrough: Register a plug-in using the plug-in registration tool
As for workflows, they need to be added in the Processes section of a solution. This section will cover workflows, dialogs, business process flows, and actions. As before, use the Add Existing button.
There is no direct support for adding plugin assemblies or plugin steps to solutions when registering with the Plug-in Registration Tool.
Your plugin steps and assemblies will always be present in the layer of unmanaged customizations ("root solution").
You can use the Plug-in Registration Tool as usual and only later manually add your assembly and steps to the relevant solution(s).
Related
I'm using modernizr in my ASP.net MVC application, and I'd like to use the inputformaction detect added in Modernizr v3. The latest version available on nuget is 2.8.3. So that means I need to add it independently from nuget. There doesn't seem to be any official full build.
The only thing I can find on their website is Download, which prompts me to create a custom build. If I select the features I'm using now, then I'll need to come back to this website every time I want a new detect, and remember all the options I chose last time. That's not really practical. I've also found that you can make custom builds using a node package and a .json definition file. I don't really feel like installing node just for this if I can avoid it.
All I want is a complete build of modernizr. Is there any way to do it other than writing a script to check all the checkboxes on their download page?
There is no such thing as a "complete" build of Modernizr. While it may be a minor inconvenience for you to rebuild when you need new detects, it can cost your users tons of time and money downloading and running javascript that is completely unneeded. There are a bunch of tools that will automate the custom build for you (bower, npm, grunt-modernizr, gulp-modernizr).
If you want a build that contains all of the options - which again is huge and horrible on perf, you can use https://modernizr.com/download?do_not_use_in_production
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
I have created a eclipse product using product configuration (.product) file. I want to display a dialog before the eclipse splash screen(the product screen) appears for some validation.Since am launching the product from the configuration(.product) file,i dont have an IApplication implementation to do the same.
Usage of startup extension is not useful as the control is given to startup extension only after loading the workbench.How this usecase can be supported ? Any help is appreciated.
Thanks,
Santhosh
The startup extension is the earliest place you could get control because, for performance reasons, your plugin won't be started until the user explicitly requests some action that requires your plugin. If you have to run some validation earlier, your two choices are to modify the base Eclipse code and deliver a modified Eclipse platform with your product or perform the validation when you install your plugin.
For completeness, I'll also note that some repackagers of the Eclipse platform (IBM Rational comes to mind. Others have done this, too) have at times included a licensing component that you might be able to plug in to.
This blog describes how to add a login-dialog as part of the splash-screen. Is this what you want to accomplish?
I am trying to add a WebService Service Task to a process in JBPM. I would like to add and configure the task directly from the process design tool.
JBPM has 3 possible tools that you can use to create a process, eclipse plugins: RulesFlow editor and BPMN2 Modeler, as well as a Onyx Designer incorporated into Drools. So far I have not managed to do this in any of them.
I was able to add the WS to the process by manually editing the process XML file (as shown here: http://mswiderski.blogspot.com/2012/07/service-task-with-web-service.html) but we need to be able to do it in a graphical tool (business reasons, don't ask). BPMN2 Modeler comes closest to the generated XML that would in theory work, but when I try to run it, it comes out with a bunch of errors.
I know that the link I provided states that the tools don't yet provide the WS functionality but maybe someone has some ideas as to this problem. Any help will be appreciated.
I don't believe you can directly create a service task from the design tools. I've followed this here :
And after you've created your work item definition, you should be able to see that you can add that service task in your process design. Just remember that you have to register that to your session before you start the process. Hope this helps
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.