anchor.diff:  
   This Processor is annotated with the `@SideEffectFree` and
   `@SupportsBatching` annotations from the
  -`org.apache.nifi.annotations.behavior`
  +`org.apache.nifi.annotation.behavior`
   package.
   
   
  
positive.code:         Processors are scheduled to run on "All Nodes", it will cause unnecessary duplication and even errors. Such Processors
          should use this annotation. Applying this annotation will restrict the Processor to run only on the "Primary Node".
  
  	- `TriggerWhenAnyDestinationAvailable`: By default, NiFi will not schedule a Processor to run if any of its outbound
  		queues is full. This allows back-pressure to be applied all the way a chain of Processors. However, some Processors
  		may need to run even if one of the outbound queues is full. This annotations indicates that the Processor should run
  		if any Relationship is "available." A Relationship is said to be "available" if none of the connections that use
  		that Relationship is full. For example, the DistributeLoad Processor makes use of this annotation. If the "round robin"
  		scheduling strategy is used, the Processor will not run if any outbound queue is full. However, if the "next available"
  		scheduling strategy is used, the Processor will run if any Relationship at all is available and will route FlowFiles
  		only to those relationships that are available.
  
  	- `TriggerWhenEmpty`: The default behavior is to trigger a Processor to run only if its input queue has at least one
  		FlowFile or if the Processor has no input queues (which is typical of a "source" Processor). Applying this annotation
  		will cause the framework to ignore the size of the input queues and trigger the Processor regardless of whether or
  		not there is any data on an input queue. This is useful, for example, if the Processor needs to be triggered to run
  		periodically to time out a network connection.
  
      - `InputRequirement`: By default, all Processors will allow users to create incoming connections for the Processor, but
          if the user does not create an incoming connection, the Processor is still valid and can be scheduled to run. For Processors
  
negative.code: Taking this approach of formatting the data for a particular endpoint and then sending the data to that endpoint within the same Processor
  has several drawbacks:
  
    - The Processor becomes very complex, as it has to perform the data translation task as well as the task of
      sending the data to the remote service.
    - If the Processor is unable to communicate with the remote service, it will route the data to a `failure` Relationship. In this case,
      the Processor will be responsible to perform the data translation again. And if it fails again, the translation is done yet again.
    - If we have five different Processors that translate the incoming data into this new format before sending the data, we have a great
      deal of duplicated code. If the schema changes, for instance, many Processors must be updated.
    - This intermediate data is thrown away when the Processor finishes sending to the remote service. The intermediate data format
      may well be useful to other Processors.
  
  In order to avoid these issues, and make Processors more reusable, a Processor should always stick to the principal of "do one thing and do
  it well." Such a Processor should be broken into two separate Processors: one to convert the data from Format X to Format Y, and another
  Processor to send data to the remote resource.
  
  
  [[naming-conventions]]
  === Naming Conventions
  
  In order to deliver a consistent look and feel to users, it is advisable that Processors keep with standard naming conventions. The following
  is a list of standard conventions that are used:
  
    - Processors that pull data from a remote system are named Get<Service> or Get<Protocol>, depending on if they poll data from arbitrary
      sources over a known Protocol (such as GetHTTP or GetFTP) or if they pull data from a known service (such as GetKafka)
    - Processors that push data to a remote system are named Put<Service> or Put<Protocol>.
    - Relationship names are lower-cased and use spaces to delineated words.
    - Property names capitalize significant words, as would be done with the title of a book.
  
  
  
  