I have two customization projects in Acumatica 2020R2. I need to reference a DAC from one of the customization projects in another customization project. The Acumatica instance that has one of the customization projects may or may not have both customization projects published.
For instance, a graph in one customization project may need to reference the VendorRebate DAC that was created in another customization project to check if a customer has a rebate for a particular inventory item before setting a price.
Is there a way to reference the DAC without having to include the DAC in both customization projects?
Also, is there a way to check if the Acumatica instance has the necessary customization project published (besides using conditional compilation)?
Is there a way to reference the DAC without having to include the DAC in both customization projects?
First of all, if the projects are ever going to be published together you should never create duplicate DAC definitions. This can lead to crashes at runtime. It doesn't matter that the DAC are identical. Acumatica Framework will not be able to resolve the conflicts properly in all scenarios for identical types. This typically results in error can't cast object of type X to object of type Y.
Also, is there a way to check if the Acumatica instance has the necessary customization project published (besides using conditional compilation)?
Use the 'Validate Customization Project' action from the customization Publish menu. Unless you dynamically load DLL references you won't be able to publish.
The Acumatica instance that has one of the customization projects may or may not have both customization projects published.
To reference a type it has to be published, otherwise it is just inaccessible.
The most common option for your use case is to create a third customization project/DLL that contains the shared types.
Otherwise you can try to conditionally deactivate feature using the IsActive property.
DAC IsActive reference:
https://help-2021r1.acumatica.com/Help?ScreenId=ShowWiki&pageid=9ca4cca5-a46c-4dda-af09-8cb8b0793c34
Graph IsActive reference:
https://help-2021r1.acumatica.com/Help?ScreenId=ShowWiki&pageid=cd70b408-b389-4bd8-8502-3d9c12b11112
To load the referenced type only when it exists you would need to put it in a DLL first and load this DLL dynamically at runtime: https://stackoverflow.com/a/18362459/7376238
Related
We have an existing project that includes customizations to SO101000 and SO301000. I am trying to publish the AmazonIntegration2017Dec project and I get an error indicating a conflict on SO301000. I assume SO101000 would also conflict. Is there an easy way to override the conflict? How do I publish two different projects that customize the same base forms?
I am evaluating Redmine, and I wonder if there is any advantage to Categories over Custom Fields?
Indeed, Categories can't be shared between projects so far and it's a strong drawback for me.
I have the feelings categories are only useful if one needs different categories between projects.
In other words, it's a project property instead of a tracker property like custom fields.
I am missing something here?
Thanks you!
In Redmine, Category is a standard field used by trackers and has different values defined for each project in the project 'configuration' tab.
Category values cannot be shared nor inherited in Redmine projects.
This is some serious drawback which is discussed by the community. A patch is available to customize Redmine, but it targets an old version of the application.
An alternate solution is to create a custom field, say Cat, which would be used as a category. That Cat field can be used by any project with any tracker.
It also means that the Cat values are shared for all projects which can be pointless if you have a 'cooking' and a 'mechanics' projects...
There are two solutions to deal with it :
Create a Cat custom field for each project, but the name of the custom field has to be unique
Use the Custom Values Per Project plugin to limit available Cat values for each project, which can be a pain i you have lots of projects
You can even possibly use a combination of those two !
That is the only solution I have found so far.
I intend to use Camunda for my product. While all camunda abilities match with my needs, i have a concern about camunda modeler controlled usage. Following are my needs in modeller
Is it possible to create custom domain specific tasks which i can simply drag-drop during modeling. It should be possible to define custom properties needed by this custom state
Can I somehow control/prevent use of custom java code/scripts by person modeling process. I want to restrict use of only my custom tasks, so that we don't end up with lot of scattered code across processes.
Can experts share views to achieve these targets?
Recently Camunda Modeler (I am using release 1.4.0, published on October 2016) has been extended to allow json template installation, which can meets all of your needs (if I understand them correctly), or at least the most of them.
You may find documentation for templates build here. The documentation is in progress, but what is already published I think it is quite clear. Briefly you have to
list all the elements you want to customise (user tasks, general tasks, service tasks, listeners, links and so on)
find out the json representation (explained in the short documentation) of each element
insert all the jsoned elements in a file (for example: myElements.json)
put the file in a specific modeler folder (see below)
close and restart the modeler
For example if you have installed the modeler in C:\Tools\camunda-modeler\, the folder to publish the file into will be C:\Tools\camunda-modeler\resources\element-templates (note that resources will be already present, but element-templates will not; it will have to be created).
If all will be right the modeler will start without any error and you will find a new dropdown list selector on the right panel (as stated in the documentation) for all the elements for which a template has been defined. Generally you have to classify each templates as either a user task, or a service task, or generic task and so on, so that when you want to use it you have to start from the generic element. For example, if you prepare in the json file 2 templates of kind of user task, say userTask1 and userTask2, if you want to insert in your new process userTask1 you have to
pick up an empty userTask
and choose from the element template selector on the right the voice userTask1, so that the empty user task becomes quickly the userTask1 (with all my custom properties with my default values)
that's it
To sum up, you may build templates with custom id and name (editable), with custom properties (editable or not, or even hidden), with eventual input/output parameters. So you may have default values properties and also tasks with simplified selections or without any selections at all.
You may find good starting examples to build your own templates at this GIT repository.
Hope that is enough to understand.
In Sitecore, the publishing restrictions access via the dialog are stored under the inherited Publish base template - for example, the Item-level Publishable checkbox is stored under __Never publish.
I had expected to be able to restrict publishing by language, but the fields above are shared between languages so apply to all.
Obviously I could unshare the fields, but I'm not sure what other implications there may be. Has anyone tried this or implemented another solution?
You can restrict the publishing of an item by language, but it is also by version. These are stored in the Lifetime field section, rather than the Publishing section.
This will allow you to mark a specific version in a specific language as unpublishable, however it won't affect all versions in that language.
Other than that, an option would be to add a new field to a base template that is Unversioned, perhaps "Publishable In Language". You could then look into adding a new step into the publishItem pipeline that takes this into account when determining whether a version is to be published - this would possibly take place just after the DetermineAction step, where Sitecore uses its own logic to determine if an item is to be published. Unfortunately that class isn't easily overridable and uses private methods, so it's not a great candidate for extension itself.
I am using EMF to allow users to create instances of a particular type of model.
An instance of a model can have 0-* Things but I'd like to be able to predefine the available Things that the user can add to the instance so that they can't just create their own.
How would I go about creating the Things using the ecore model?
If a Thing was just a String then it would be fine - I could use Enums. But a Thing is a type of it's own and consists of other stuff (like a name, version etc.) and I don't know how to give a predefined set of these to the user to choose.
Any ideas?
You have the possibility to use constraints or *EOperation*s.
For a better usability you should use a own dialog implementation. An example of a own implementation with given choices you can find here:
How can I control which instances are available as choices when editing a property in the properties view?
You should also implement a own property source to support the properties editor:
Recipe: Create your own property editor in a generated application