Quarkchain The Master of Next Generation BlockChain 3.0

!DISCLAIMER: This is NOT financial advice!

Apprehension:- Quarkchain has been able to find a solution for the most basic problems existing chains are facing, Scalibility and speed. They have separated their chain with two layers in a way that all the transacations are not processed by all the nodes, instead they have created small sub blockchains , which process the transactions passing through it. In this way more number of transactions can be processed. The other layer then confirms the blocks from underlying sub blockchains, which increases the security as well.

The core I believe is in allowing multiple smaller nodes to form together and run as a full-node. The more full-nodes there are, the higher the security. This is a very smart way to further increase security for the whole network and all its users.

Quarkchain supports “cross-shard” transactions. Only 1 account is needed for all shards to be managed

• A guaranteed security by market-driven collaborative mining.
• Anti-centralized horizontal scalability.
• Efficient cross-shard transactions and simple account management.

All of these features will desrupt the industry. Imagine great projects like Bitcoin, Ethereum, EOS, Zilliqa, Paypal and Alipay all in one, combining their best features in addition with Quarkchain’s unique features.

O2A import Issue in DS

If you are getting below issue(Error) while importing the O2A cartridge .

Problem :-
Order Template Element Types Conflict
  /ControlData/Functions/FulfillBillingFunction
/ControlData/Functions/SyncCustomerFunction
/ControlData/Functions/InitiateBillingFunction
/ControlData/OrderItem/ExternalFulfillmentState
/ControlData/Functions/ShipOrderFunction/transformedOrderItem/ExternalFulfillmentState
/ControlData/Functions/InstallOrderFunction/transformedOrderItem/ExternalFulfillmentState

Solution :-

Please follow below simple steps

1. In Design Studio, from the Window menu, select Preferences, then select Oracle Design Studio, and then select Order and Service Management Preferences.
2. In the Order Template Inheritance field, do the following:
   • To allow significance defined on an order template data element to be inherited from child orders and other order contributors, select Inherit significance from order contributors.
   • To allow keys defined on an order to be inherited from child orders and from other order contributors, select Inherit keys from order contributors.
   Design Studio sets the order template inheritance preferences you specify as a global preference.
3. Click OK.
   Design Studio saves your order template inheritance preferences and closes the Preferences dialog box.
4. Clean and build the cartridges.
5. Resolve any problem markers that may result from order template inheritance discrepancies in your cartridges.

reference  Oracle  

Simple Steps to install The Oracle middleware AIA

Simple Steps to install The Oracle middleware AIA for integration  with OSM,BRM and CRM

1. RCU  11g
2. SOA 11.1.1.6
3. SOA Domain Creation
4. SOA Patch installation
5. OER
6. AIA FP 11g
7. AIA FP Patch
8. PreBuilt Installation 11.5
9. Configuration of Siebel OSM using DCW
10.  PIP patch installation
11. PIP Deployment

Below is useful link with simple steps to configure the DCW for OSM/CRM/BRM

https://docs.oracle.com/cd/E24010_01/doc.111/e23118/commsordertocashcrm.htm

About Revision Order In OSM

About Revision Order In OSM

    The new version of the order includes all of the data relevant to the order, not just changed data.
 
    A revision Order can have :-Change ,Remove ,ADD in existing Data.

Steps In OSM for Revision Order :-
 
   1. OSM Check for Order Amendable or not, in the Amendable tab of Order you can check it .
 
   2. OSM checks in-flight orders for a matching value to an order key,in the Amendable tab of Order you can check it how to find the Order Key and Version
 
   3. Now OSM check the base order  allowed to be amended.
       3.1. Order Should not be in Not Started, Completed, or Aborted state(OLP).
      3.2. Check for PONR, should  not passed the point of no return.
      3.3. Check for Version , Lower version will get ignored .

If a revision cannot be processed, or if the order life-cycle has not allowed the revision,
the revision order is set to the Failed state, and the base order continues to be processed.
 
   4. Analyzing order data
         4.1 At order Level , revision order data and the base order data .
        4.2 At task level , OSM compares task data for each task in the order process to further validate the compensation requirements for DO,REDO,UNDO .
        4.3 Check for significance data .

   5. For orchestration orders, the order components of the orchestration plan are analyzed to                determine which order components need to be redone, undone, or done for the first time (amend do).

The tasks of the sub-processes run for each of those order components to be compensated are also analyzed.

   6. Any order components with data that has changed as a result of the revision are redone.
       Any order components that have been processed but are no longer required in the revision are undone in reverse dependency sequence.
Any order components that are inserted as new requirements are fulfilled   

Intra and Inter order dependencies

How to achieve intra and inter order dependencies

1.Intra-Order Dependencies Need to configure in product specifications(fulfilment pattern) .

2.Inter-Order Dependencies in Order item specifications.


1.About Intra-Order Dependencies

 Dependencies that can be created within the same order
   a). Order item
       Order Item Dependency Wait Conditions
      Order Item Dependency Wait Conditions Based on Data Changes

   b).Modeling a Product Specification Dependency
       You can define dependencies across different order items by basing the dependency on the        product specifications of the order items.
     For example, you can create a dependency that specifies to provision fixed services only after broadband services have been provisioned
 
c).Modeling an Order Item Property Correlation Dependency
       Using properties correlation is the most flexible way to configure dependencies. You use this method to create a dependency on two different order items that share the same order item property.

 As with other dependencies, you specify a blocking component (the From Component field) and a waiting component (the To Component field), but you also

 enter an XQuery expression to select the order item property that order items in the To Component field must share with order items in the From Component field

2.About Inter-Order Dependencies

An inter-order dependency is a dependency between order items in different orders.
You typically configure this type of dependency to manage changes to an order when that order has passed the point of no return and cannot be amended. However,

you can also use inter-order dependencies for other purposes, such as managing fulfillment functions on different systems, load balancing, and so on.
   

About Behaviors

About Behaviors
 Behaviors means to control  the data element values , there are various way  and 3 level to achieve the it.

Examples of behaviors 

You can specify the maximum allowed digit for phone number field .

You can add the values of multiple fields like first name and last name  and display the sum in another field like customer name(first+last) .

You can specify the minimum and maximum times that a data element can be used in an order.

For example, an order might require that exactly two IP addresses are added.

OSM Behaviors

• Calculation Computes the value of a field value based on a formula that references order data.
• Constraint Specifies a condition that must be met for the data to be considered valid.
• Data Instance Declares an instance that can be used by other behaviors.
• Event Specifies an action that is performed when data is modified.
• Information Specifies the label, hint, and help information for the data element instance.
• Lookup Specifies a set of dynamically generated choices from which you can select.
• Read Only Specifies whether a value can be modified or not.
• Relevant Specifies whether data is visible or hidden.
• Style Specifies the visual appearance of fields.

Evaluating Behavior Levels

In Design Studio, you can create behaviors for data nodes at three levels:

• Data element level (most general)
• Order level (more specific)
• Task level (most specific)

OSM evaluates behaviors from the general level to the specific level. For example, OSM evaluates behavior conditions defined at the data element level first, and evaluates behaviors defined for data nodes at the task level last. At run-time, OSM determines which level to use for a behavior type and data node combination and evaluates rules from that level only.

For example, consider that you create a Calculation behavior at the data element level, and for the same data node you create a Calculation behavior at the order level. In this scenario, OSM would never evaluate the conditions defined for the Calculate behavior at the order level (unless you force evaluation using the Override or Final options), even if all of the conditions defined for the behavior at the data element level evaluate to false.

OSM does, however, evaluate different types of behaviors defined for a data node at different levels. For example, if for the same data node you define a Calculation behavior at the data element level and a Constraint behavior at the order level, OSM evaluates the conditions for both behaviors at run-time.

You can force local, specific exceptions to the way behaviors are evaluated for a given node by selecting the Override and Final check boxes on the appropriate Behaviors Properties view Details tab in Design Studio. You can select the Override attribute to allow the behavior to take precedence over any other behavio

About Using Automation

Two basic types of built-in automation plug-ins:
1.Sender :-The plug-in will receive data, perform some work, then send data to external systems .
2.Automator :- The plug-in will receive data and perform some work .

Event Type
1.Internal Event Receiver :- An event occurs within OSM,creates a message and sends it to the internal message queue.
2.External Event Receiver :- An event occurs in external system and send message to external queue and automation framework subscribes
 to the external message queue through the information you define on the External Event Receiver tab of the automation definition


 AbstractAutomator
        |
|
       \/
 AbstractSendAutomator

 The AbstractAutomator can receive information, either from OSM or from an external system.
 The AbstractSendAutomator inherits this ability, so it can also receive information from OSM or from an external system;
 however, it can also send information. If the custom automation plug-in you are writing is to send a message,
 it should extend the AbstractSendAutomator class; otherwise, it should extend the AbstractAutomator class