Did not find a more suitable SE site, so asking this here.
In BPM, there are more-or-less standard ways of marking activities - like Start (green circle), Stop (red circle), Conditional (yellow diamond). An example I found is here.
Conditional is basically an 'if' in any programming language.
What I could not find any example of is a 'switch'.
I know that one could use multiple Conditionals, but I have to implement a user friendly way, so I'd like to know if there is any standard way of representing such a thing in BPM.
It depends on what you mean by "switch". If you want to switch process flow in one or another way you can use Complex Gateway. A Complex Gateway allows the modeler to specify any arbitrary rules needed to determine how to emit tokens or process arriving tokens.
BPMN Complex Gateways can be used for splitting or merging a complicated process flow scenario. However, it is not recommended practice as there are simpler and more practical inclusive and exclusive gateways. There is always better to use their combination. You can learn more about complex gateways here.
Related
the custom_federated_algorithms_2 tutorial presents a local_train function using tff.federated_computation.
There a comment saying "while we could have implemented this logic entirely in TensorFlow, relying on tf.data.Dataset.reduce...":
regarding this comment:
I didn't manage to actually convert the code to using tf.data.Dataset.reduce seems non-trivial and the debug comments really don't help
I wonder what is the motivation of using federated_computation in cases like this, I looked all over the guides and real did find an explanation for what is going on here and when should we use it.
thank's!
Addressing these two in order:
It may not be trivial to adapt the code given directly to use tf.data.Dataset.reduce; that comment is intended to call out that the logic expressed here is also expressible using the dataset-reduce primitive, as effectively it only represents a local reduction, there are no communications across placements happening here.
There are at least two distinct purposes of this demonstration. One is to show that TFF as a language does not necessarily rely on the in-graph looping constructs of TensorFlow; another is to demonstrate the ability to "capture" values using the federated computation decorator. This could be used to natively capture something like learning rate decay in TFF, by evaluating a function of the round number and closing over it in the manner above, though there are other ways to implement similar functionality, as demonstrated here for example.
I personally find this pattern a little confusing; reading into the question behind the question a little, I agree that it is confusing to use a federated_computation decorator where there is no communication happening. When writing TFF, I generally express all my local computation in TensorFlow proper (usually in a functional manner), and let TFF handle the communication only. The purpose of the second tutorial is to show that TFF proper is actually much more flexible than indicated by restricting oneself to using the pattern just described.
For my bachelor´s degree I got the task to implement a B2B communication for an ERP system developed by the company I currently work for. Because it should also be able to communicate with other software I consider using EDI messages (EDIFACT) or maybe cXML. What is the best way to approach this task.
I had the idea to translate the EDIFACT message into xml defined by one xsd describing every EDIFACT message.
Then I would write the xml into the database or to business objects using a selfwritten mapper.
For writing EDIFACT messages I just use the same methods the other way round.
I thought using XML transformation first would be easier for the mapping and gives the opportunity using the xml for other purposes like writing other edi formats.
The other idea is to just use cXML and map it.
What is the best approach to this task?
You're essentially designing and implementing a public facing API for the ERP, so you need to consider security, reliability, non-repudiation, impact on business process under normal and abnormal conditions.
You'll also need to consider (ask) what sorts of information your customers will need to exchange with their partners (master data, transactional messages, financial information, etc).
I'd start by looking at the most commonly exchanged messages in the industry most representative of the ERPs users - look for message content and structure.
whether you choose to use EDIFACT, ANSI X12, cXML, XCBL, GS1XML, ebXML or something else is less important than good documentation and flexibility. it's unlikely that your choice will be exactly what any of your customers need without further transformation. you don't want to invent a new any to any transformation tool, and you probably don't even want to bundle an existing one.
i've been trying to figure out how to deal with Business Rules in the following format:
a booking has 1 to n (n = 200) articles
problem P shall be handled by the System XYZ
a specifict data-class shall be supported in the System XYZ
the communication to the customer shall be done by the organization Z.
it is possible to change a specific value in an order
the system XYZ shall be able to evaluate if a customer is able to pay monthly rates
in addition, many rules i got explain certain things that need to be fulfilled in order to let a future system work correctly. In my eyes, these rules are technical requirements. So, what would be the best choice? Hard-coding these Business Rules in Business Processes (it just sounds so wrong) or embedding a Business Rule Management System (with a Rules Engine) next to a Business Process Management?
My guess is that a Rule Engine is not the best choice for this. There are sometimes more than one possibilities and scenarios written down in each Business Rule and the common "if-then" statement does not apply in the most cases.
So i found out that in most cases there is this "if-then" statement (literature etc.), but then the SBVR from the OMG comes in (Semantics of Business Vocabulary and Business Rules). It confuses me because there it isn't required to formulate rules with "if-then" et cetera.
I assume that these rules are not specifically meant to be built in a rules engine, but rather kept an eye on during the implementation of the software and after this process. Yet i think that these Business Rules might change. Wouldn't it be naive to hard-code them in Business Processes?
If there's anyone with a hint, i'd be very thankful.
BR
Yeah, you just need to choose the right tool for the job. You should take a look at the Drools and JBPM projects. Where the main goal is to make the rule engine to coexist with the process engine. So for some of those "Rules" you can create a business process to take care of it and for another one you can just write a proper business rule. And the third option is to mix both worlds.
I watched some videos, read some blogs about it. SO has many questions and answers on that subject but I can not find anywhere exact answer for my question.
Almost every question and answer has a lack of usage context.
I have one middle sized, asp.net-mvc, monolith application which is running in one process on IIS. I want to (refactor and) go all the way with DDD (and CQRS without separated storage for reads and writes for now) but for me it looks like impossible mission without breaking some rules/guides/etc.
Bounded Context
For example I have more than one BCs. Each should not cross their boundaries which means should not share their storage. Right?
It is not possible if you use the whole known (everywhere scattered over the web) solution to work with NHibernate session and UoW.
Aggregate Root
Only one AR should be modified in one transaction. When others ARs are involved should introduce eventual consistency (if I remember those are Eric Evans words).
I try to do it but it is not easy in app like that. Pub/Sub not working as desired because if event is published then all subscribers are take their action within one transaction (NSB/MT does that way).
If event handlers wants to modify others ARs they should be executed in separated transactions, right?
Is it possible to deal with it in monolith application (application where whole code works in one process)?
It is not possible if you use the whole known (everywhere scattered
over the web) solution
[...]
if event is published then all subscribers are take their action
within one transaction
I think you're setting yourself useless and harmful constraints by trying to stick to some "state of the art".
Migrating an entire application to DDD + CQRS is a massive undertaking. Some areas of it don't have well-documented beaten paths yet and you'll probably have a fair bit of exploration to do. My best advice would be to stay at a reasonable distance from "the way people do things". Both in traditional ASP.Net web apps because mainstream practices often don't match the way DDD+CQRS works, and in CQRS itself because the case studies out there are few and far between and most probably very domain specific, with a tendency to advocate the use of heavy tools which may not make sense in your context.
You may need to think out of the box, adopt things incrementally and refrain from goldplating everything. You'll be better off starting with very simple implementations that suit your needs exactly than throwing a ton of tools and frameworks at your codebase.
For instance, do you really need a service bus or could a simple Observer pattern suffice ?
Regarding NHibernate, most implementations out there use a (single) Session Per Request approach, but just because it's the most popular doesn't mean it's the only one. Have you tried using multiple ISessions (one for each BC) available at a more programmable level, such as per-action, or managed entirely manually ? Conversely, have you considered sharing a database between Bounded Contexts at first and see for yourself if that's bad or not ?
I want to create a simple "multi-agent" system consisting of three agents. For each agent, there is a type created encapsulating the mailbox processor. There are attributes common to all the agents (position, id etc.) and functions (sendMessage, move) and agents differs from each other with the implementation of mailbox processors (how the messages are processed). In addition, they may differ by other functions specific to particular agents. Every agent should also contain (as one of its attribute) a list of other agents, to whom it will be sending the messages. This is a just very simple model based on which I plan to play with the mailbox processors in F#.
In OOP, this would mean creating an agent interface (or abstract class), and all the particular agents would be inherited from this interface with their own implementation.
I know OOP is possible in F#, however I would rather stick to pure functional design. However, it seems to me that OOP is the most suitable approach in this case. I would be glad if you could give me any idea with respect to functional (F#) design? Thank you.
First of all, the functional style and object-oriented style in F# are not really in conflict.
Functional style consists of using immutable types, pure functions without side-effects and F# data types such as discriminated unions, functions etc.
Object-oriented style is more focused on how you organize code (using classes and interfaces), but the code can still be purely functional without using any mutable state.
In agent-based systems, it makes a good sense to use functional style in the implementation of the agent, but to organize the agents using classes. I think this is probably the best practice in F# (see also this article on encapsulating F# agents on MSDN).
In your example, you're saying that an agent keeps a list of other agents that it sends messages to. There are a few alternatives worth considering (if you want to avoid interfaces):
Expose an F# event (Event<'T>). This way, the agent simply exposes a notification and does not have to explicitly manage a list of other agents (and this design also allows other types of subscribers).
Keep a list of functions. If you just need to send messages to other agents, then you essentially need just an interface with a single method. In that case, you could keep a list of functions such as
Message -> unit.
I generally prefer exposing events - this way, the system is less tightly coupled and you can more easily compose agents in various ways (they do not have to implement a specific interface to be composed). This article discusses agent-based architectures from a higher-level perspective, and may be useful too.
Why would you want to stick to a pure functional design ? F# allows a clean combination of functional and OOP principles and I would make use of both mechanisms and leverage the power of the language.
If you want to combine the functional and OOP aspects, I would start by making your objects immutable. Thus you're using objects, but in a functional paradigm.
You have come up with an OOD, is it surprising that an OOP solution seems the most natural?
If you rewrote the design description with processes, and data transformations in mind it would naturally fall out as a FP design, and sound really awkward in OO with lots of 'er classes. As it is there is almost zero description of the types of data or what transformations need to take place. At first glance I would say an agent is a function of three arguments a mailbox, a message handler(or list of message handlers), and a list of other agents' mailboxes to contact. If future dispatch is based on the message then the message handler is a function of two args. the message, and the list of mailboxes.