Recently Started off on Camunda BPMN And immediately felt the need of Extending the properties under extension elements for my usecase.
Currently Camunda offers CamundaProperty which is good enough, but not for my use case where I want to have a specific property tag across the BPMN and collect only those properties.
Example:
<bpmn:extensionElements>
<demo:properties>
<demo:property name="entitlement" value="assign" />
<demo:property name="processProp" value="enabled" />
</demo:properties>
<camunda:properties>
<camunda:property name="entitlement" value="assign" />
<camunda:property name="processProp" value="enabled" />
</camunda:properties>
</bpmn:extensionElements>
I am Extending BpmnModelElementInstanceImpl class to achieve the same and register my demo tag in the xml.
But the process engine fails to recognize the tag.
Please guide me in solving this issue.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What are some common best practices one needs to consider while developing Apps in MuleSoft for clients, focusing Anypoint Studio 7.x.x and Mule 4.
List down your recommendations, which you have followed with any clients.
Please Note: I asked this general question to have a dedicated section of MuleSoft Development Best Practices on SO, rather than having similar titles where users having their personal agendas\user driven case scenario.
Mule Developers must considered this to be a critical topic.
Given below are the wide range of MuleSoft best practices which are involved during App development phase.
Development best practices are commonly divided into three categories:
Mule General Best Practices
Mule Munits Best Practices
Mule Error Handling and Exception Scenario Best Practices
Mule General Best Practices
Note: Suggestions are placed in <>. These are just best practices, not a compulsion.
Naming Conventions
Flow and SubFlow Names. <Must use camelCase>
XML files and properties files <Must be all lower case with '-' in between words>
Other common files (Examples, JSON files, Scripts) <Must use camelCase>
All the rest (Components, Transformers, Scopes, Flow Controls). <First letters of each word must be capitalized. Spaces must be used between words>
Property Parameterization
Configuration Properties. <All configurations must be declared as *key=value* in the property files>
Environment Based Properties. <Configuration properties must be segregated into files based on the *Environment* we deploy the app. Example "config-dev.properties", "config-qa.properties", "config-prod.properties">
Runtime Property Variables. <Should be used to fetch appropriate ".properties" files needed for the environment we deploy. Example, name your environment files as "/config-${env}.properties" using Configuration properties in global elements and pass 'env=dev' or 'env=qa' as a Runtime variables in Run Configurations. We can also pass global arguments like 'crypto.key=w4ref$%wrfw3', used to decrypt encrypted values>
Externalizing Transform Message Code to dw Script files. <A common rule of thumb is to use script files when the lines of code is greater than 10>
RAML and Project Files Folder Structuring
Place all the .properties files in src/main/resources/properties
Place all dw script files in src/main/resources/scripts.
Place the RAML examples, libraries, dataTypes, securitySchemes and Traits in dedicated folders while designing in Design Center.
Keep a separate file for API Kit Router and all its generated flow.
Error handling must have its own separate file. Error flows must not be seen anywhere else apart from this file.
Move all Connector Configurations/Global Elements into a separate 'global-config.xml' file. <This keep the rest of mule xml files clean and tidy>
Hard coded values
Must be aware of which code values you must 'Hard code' and which ones not.
Most Global elemental configurations must be property parameterized rather hardcoded. Example, 'Reconnection Strategy, 'Connection Idle Timeouts', 'Max Idle Timeouts', 'host', 'port', 'usernames', 'passwords' and more.
Property Value Encryption. Critical Information must be encrypted. <Using secure-properties-tools.jar or Mule property editor>
Autohide sensitive Property Values passed in Runtime Manager Tab of cloud hub. <Achieved using 'mule-artifact.json'>
Using functions, local/global variables in Transform messages to enforce DRY
Add detailed inline XML comments for flows, choice, etc.
Add descriptive multiline code comments for any complex transformations in Transform messages.
Replace long repeating 'if/else' statements 'with match/case' in data weave.
If flows are getting big using more choice routers. Refactor each choice scope into its own subflow.
A good rule of thumb is that if you have to scroll the Mule canvas back and forth to see the whole flow, it's too complex and should be rewritten.
Avoid Mule Async Scope Calls as much as you can. It caused data integrity issue, based on several developer complaints.
Do not use mule-objectstores for fast-long repeated operations. Know your TPS. Always clear your object stores in your mule cyclic execution in relevance to the requirement from time to time.
Keep a track of each 'variable' initialized in the flow executions. Always make sure to clear or remove variables once finished using them. <Helps you to have a clean process, removing unnecessary code manipulation and heap limitations>
Change your mule loggers from 'INFO' to 'DEBUG' after done development. <Helps you by not over-burdening the Mule APP when deployed in cloudhub. Keeps the mule health monitor in check, so that the APP does not auto restart>
Make sure to never cross an App's 70 percentage CPU usage shown in dashboards. Create Apps accordingly.
18. Be always aware of Data losses caused by Fatal Errors\Application Restarts. <Always use a backup data centers like AWS, Database, Object stores, Mule Load Balancers etc>
Mule Munits Best Practices
Never forget to use Spy and Asserts.
Scenarios based test cases.
Success Scenarios. <Have one major test case to run through the entire API once>
Failure Scenarios. <Have multiple test cases for each flow or subflows, testing for all possible failure situations, like testing mapping, choice routing etc>
Always mock all external service calls, like HTTP, DB, SQS Connectors. <Never call your actual endpoints in Munits>
Consider to put your test payloads in 'src/test/resources/testExample.json' but not directly in the Mocks or Events. <use #[MunitTools::getResourceAsString('testExample.json')]>
Include the files needed under 'src/test/resources' for Munit Test Runs, similar to having 'src/main/resources'.
Mule Error Handling and Exception Scenario Best Practices
All Error status codes must be included appropriately as per the requirement.
Errors must be separately specified in a 'global-error-handling.xml' file.
All Exceptions\Errors must be properly branched as given below
System Exceptions <Source related data exceptions>
Business Exceptions <Target\End System exceptions (Not to be bothered by the Mule APP, but must be handled)>
System\Application Errors
Admiring the usage of object stores and Data Queues for failed messages and record reprocessing.
Having a Retry mechanism for all HTTP based errors.
Can you imagine all the hours of pain we can avoid by following some simple recommendations.
Hope you this helps !
No matter how many times I try, I cannot get my HTML Helper extension method to work. Here's the test steps I've created, if someone wants to try it out themselves:
Using Visual Studio 2012, I create a new "Visual Basic ASP.NET MVC 4 Internet Web Application" using the "Internet Application" project template.
I create a folder "~/Views/Helpers"
I create a file "DisplayForPropertyHelper.vb" and add the following code:
Namespace TestProject.Extensions
Public Module HtmlHelperExtensions
<Extension()>
Public Function DisplayForProperty(helper As HtmlHelper) As MvcHtmlString
Return MvcHtmlString.Create("TEST")
End Function
End Module
End Namespace
I open up "~/Views/Web.config" and change the following (I add the extensions namespace):
<system.web.webPages.razor>
<host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<pages pageBaseType="System.Web.Mvc.WebViewPage">
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Optimization"/>
<add namespace="System.Web.Routing" />
<add namespace="TestProject.Extensions"/>
</namespaces>
</pages>
</system.web.webPages.razor>
Compile the project
Choose ANY razor view file, and type #Html.Display-and you will see that the extension method does not show up.
Add to the razor view file #Imports TestProject.Extensions then save and close the file.
Reopen file, and type #Html.Display-and you will see that the extension method does not show up.
You can even try closing VS2012 and reopening the project. Won't make a difference.
I have been battling with this for weeks now. All answers I've found on here and elsewhere are NO help. Someone must have an answer.
Make sure that you prefixed your namespace with your application name. So for example if the application you created was called MvcApplication1 in your ~/Views/web.config you should put:
<add namespace="MvcApplication1.TestProject.Extensions"/>
and not just:
<add namespace="TestProject.Extensions"/>
Yeah, I guess, it's one of those VB.NET thingies :-) Oh and don't forget to close and open the Razor view after making changes to the ~/Views/web.config file, otherwise your changes won't be taken into account immediately (if you run the application it will work of course).
This is not really an answer, but I write it here in hopes to only add (a little) the overall picture.
For me, I discovered that my 'Module' class was not explicitly being modified as 'Public' (the default is Friend when you don't specify a modifier, and that was what was killing mine)
Yes, I realize the O.P.'s example Module is already declared Public already.. but, I just didn't catch it in my own code stack and figured I'd highlight that requirement. As a native C-sharper having to play VB.Netter for the past five years, I get tired of translating C# snippets manually.. and tend to rely on code converters. So, the nifty HtmlHelper I found and converted didn't quite come out right and I neglected to look for this issue in the code snippet that had been generated for me.
As noted in the prior comments, I'd also like to join the chorus and state the following:
I was doing all of the above (so I thought, as I checked the O.P.'s checklist over and over)
I also find writing HtmlHelpers nearly impossible for VB.NET MVC 4 (until today) - the requirements seem to be supported in such a fragile manner
I also despise having to use VB.NET for developing MVC sites (but, I must live with it.. it's part of the legacy code I inherited coming on board my company)
As much as I despise it (for reasons like this one) I will say everything does seem to be supported if you are determined enough to figure it out. (thanks StackOverflow!)
Prior to this discovery, I thought maybe it wasn't working because my application name had dots in it (MyCorp.Web.WorkOrders) vs. (MvcApplication1).. but, my tests conclude that the application name was not the issue. Either way you name it, it will work.
Again, as #Darin already pointed out.. you certainly must include the solution name(space) as part of the 'add namespace' declaration in views/web.config
I want to change Spring AOP to pure aspectJ in spring framework.
Spring AOP is used like below.
<aop:config >
<aop:pointcut id="testopiaLogging" expression="execution(public * cosmos..*SVC.*(..))" />
<aop:aspect ref="testopiaLoggingAspect">
<aop:after-throwing method="throwError" throwing="exception" pointcut-ref="testopiaLogging"/>
<aop:after-returning method="log" returning="retVal" pointcut-ref="testopiaLogging"/>
</aop:aspect>
</aop:config>
and I'll change it to pure aspectJ accroding to below url's page
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-using-aspectj
spring-aspect.jar is set in classpath.
So I made aop.xml.
<aspectj>
<weaver>
<include within="cosmos.*" />
</weaver>
<aspects>
<aspect name="com.sds.testopia.logger.aop.TestopiaAspect" />
</aspects>
</aspectj>
Next, I can't know very well.. I guess that I will use Load Time Weaver and
Log Aspect File have to change .aj foramt using aspect, point-cut keyword and making jar..
I want to get specific and detail explanation. thx.
AspectJ doesn't work with Spring's XML-style AOP. You need to use either traditional AspectJ (.aj) or the annotation based #AspectJ (.java) format. But you can't create AspectJ aspects using XML (only Spring AOP aspects).
I am not sure what this error is. Thought I would ask you guys on stack overflow what it could be. I had to change the contract on my service, on a test client that I used, I updated the service reference. Now I am getting this warning. How can I resolve this particular issue.
I found the answers in What does this WCF error mean: "Custom tool warning: Cannot import wsdl:portType" help. In my case, I chose unticking the 'Re-use types' box and that solved it.
Additional Thoughts: SOA, Distributed Objects, & Coupling
The ”Service Oriented” Vision implied by a WSDL and the WS-* standards is that the WSDL itself tells your client everything you need to know use the service. On this vision, unticking the 'Re-use types' box is the correct approach. You shouldn't be reusing types from anywhere except the wsdl.
Ticking the 're-use types' box is more a "Distributed Objects" approach: your client and service become coupled through the types in a shared dll. This is a strong distributed dependency. If the shared objects are updated, the service and all its clients must be updated, all in sync with each other. This is one reason why distributed objects fell very much out of favour and SOA took over.
Unless you company chose (possibly accidentally, by sharing libraries on a Nuget feed) a distributed objects architecture, and understand the costs, I would always untick the re-use types.
It reduces coupling.
This was the first answer I found when searching for a similar problem, but my issue was a [DataContract] attribute applied to an enum without any [DataMember] attributes, making an empty data contract.
I used this as a resource:
http://www.lukepuplett.com/2010/02/empty-datacontract-causes-misleading.html
It appears as though it is advisable to allow WCF to infer a datacontract for enums.
I find that this also can be solved by using the ?singleWsdl instead of just ?wsdl at the end. There are multiple WSDL files that are linked to, so something too naive to browse them can throw errors.
We had this problem today when trying to convert and old WSDL to a .cs fike with dotnet-svcutil.
We solved by replacing:
<xsd:complexContent>
<xsd:restriction base="xsd:anyType" />
</xsd:complexContent>
With
<xsd:complexContent>
<xsd:sequence>
<xsd:element name="deleteThisField" type="xsd:string" />
</xsd:sequence>
</xsd:complexContent>
And then manualy delete the deleteThisField string in the generated result code.
Has anyone tried the ActiveRecord Intro Sample with C# 3.5?
I somehow have the feeling that the sample is completely wrong or just out of date. The XML configuration is just plain wrong:
<add key="connection.connection_string" value="xxx" />
should be :
<add key="hibernate.connection.connection_string" value="xxx" />
(if I understand the nhibernate config syntax right..)
I am wondering what I'm doing wrong. I get a "Could not perform ExecuteQuery for User" Exception when calling Count() on the User Model.
No idea what this can be. The tutorial source differs strongly from the source on the page (most notably in the XML configuration), and it's a VS2003 sample with different syntax on most things (no generics etc).
Any suggestions? ActiveRecord looks awesome..
(This was too long for a comment post)
[#Tigraine] From your comments on my previous answer it looks like the error lies not with the configuration, but with one of your entities. Removing the "hibernate" corrected the configuration so that it geve you the real error, which appears to be that the entity "Post" is not properly attributed for ActiveRecord to create its mapping.
If you further down in the error that it gives, it likely has some details as to what about "Post" failed.
Some common things include:
THe class does not have the [ActiveRecord] attribute.
There is no property with the [PrimaryKey] attribute.
There is no matching table called "Post" (or "Posts" if PluralizeTableNames is "true").
There is no matching column(s) for attributed properties.
Your attributed properties and public methods are not virtual (this one kills me all the time).
The 'hibernate' portion of the key was removed in NHibernate version 2.0.
This version is correct for NHibernate 2.0 onwards:
<add key="connection.connection_string" value="xxx" />
Edit:
I see that the quickstart doesn't come with the binaries for Castle and NHibernate. You must have downloaded the binaries from somewhere; it would be helpful if you could provide the version number of your NHibernate.dll file.
Confusingly, at least SOME of the quickstart has been updated to be current with NHibernate (NH) 2.0, but the latest 'proper' Castle release is still the 1.0 RC3 (almost a year old now), which does not include NH 2.0.
You can go two ways. You can continue using Castle RC3 and in this case you will indeed need to add the 'hibernate' prefix to your configuration entries. Or you can download a build of Castle from the trunk, which should be running against NH 2.0. The problem with the latter approach is that some of the other breaking changes introduced in NH 2.0 might not be fixed in the quick start.
Delete the "hibernate." part for all configuration entries. Your first example is the correct one.