Activities

• Add a Time-Based Event
• Add a Production-Based Event
• Add a User-Defined Event
• Add a Product-Change Event

• When there are no variables configured in the Display associated with an Autolog sheet or a Production Unit and the Display type is not set to custom
• When the Display associated with an Autolog sheet or a Production Unit is configured to create activities with titles corresponding to the titles of variable groups, but the variable groups have the same title
• When the option to create activities is set to False in the Display associated with an Autolog sheet or a Production Unit

1. The user performs a custom activity in the Activities application.
2. The Activities application initiates the Handshake protocol by sending a message to the form and checks whether the URL of the custom form is valid or not.
   • If the URL is valid, the Activities application receives the message back. The application then adds an event listener to hear from the origin and then posts the message with the variable data to the custom form.
   • If the URL is not valid, a page not found 404 error message appears in the Activities application.

• Window objects such as between a page and a window that the page spawned.

  Example: The window.postmessage() method is used when you select the option to access the URL of the custom in a separate page.

• A page and iframe such as between a page and an iframe embedded within the page.

  Example: The window.postmessage() method is used when you select the option to access the URL of the custom form embedded within the window displaying the autolog sheet or as a replacement of the window displaying the autolog sheet.

targetWindow.postmessage(message, targetOrigin, [transfer]);

• targetWindow: A reference of the custom form window that receives the message.
• message: Data to be sent to the custom form. The data is serialized using the structured clone algorithm. The algorithm enables you to pass a broad variety of data objects safely to the destination window without serializing them.
• targetOrigin: The origin of target window. By default, asterisk (*) is set to indicate no preference. The postMessage() transmits vital information. It is absolutely critical that this argument be a URI whose origin is the same as the intended receiver of the message containing the password to prevent interception of the password by a malicious third party.
• Transfer: A sequence of transferable objects that are transferred with the message. An optional parameter not used in the Activities application.

window.addEventListener(???message???, receiveMessage, false); 
function receiveMessage(event) 
{ 
    if (event.origin !== "http://example.org:8080") 
        return; 
} 

• data (event.data): The information passed by the Activities application.
• origin: The origin of the window that sent the message at the time postMessage was called. In the code snippet, the http://example.org:8080 is an example of origin.
• source: A reference to the window object that sent the message. You can use this property to establish two-way communication between two windows with different origins.

• If you do not expect to receive messages from other sites, disable the Activities application to add any event listeners for message events.
• If you expect to receive messages from other sites, always verify the sender's identity using the origin and possibly source properties. Any window (including a URL, for example, http://evil.example.com) can send a message to any other window, and an unknown sender can send malicious messages. You must verify the syntax of the received message.
  Note: Failure to check the origin and possibly source properties enables cross-site scripting attacks.
• Always specify an exact target origin, not an asterisk (*) in the Activities application configuration when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge. Therefore, the site can intercept the data sent using postMessage.

{
                "loggedUserInfo": {
                    "token": <<token>>
                },
                "header": {
                    "activityId": <<activityId>>,
                    "activityType": <<activityType>>,
                    "activityDescription": <<activityName>>,
                    "startTime": <<startTime>>
                },
                "productInfo": <<productId>>,
                "processOrderInfo": <<processOrder>>,
                "variableInfo": <<variable_data>>,
                "activityStatusInfo": {
                    "statusId": <<Activity_statusId>>,
                    "status": <<Activity_status>>,
                    "readOnly": <<readOnly_status>>
                },
                "userConfigurationDetails": <<customActivityUser>>
            }

• loggedUserInfo: Provides the user name and token. The UAA token is required when the custom forms use the public REST APIs provided to save variables into SOADB.
• Header: Provides the activity ID, activity type as Production, Time-Based, or User-Defined, activity description, and start time of the activity.
• ProductInfo: Provides the ID, name, and value of the product.
• ProcessOrderInfo: Provides the ID, name, and value of the process order.
• Variables: Provides the list of variables with ID, name, data type, and value.
• ActivityStatusInfo: Provides information regarding whether the activity is locked, read-only state, or modifiable.
• userConfigurationDetails: Provides the user name and password configured in Plant Applications.

• Same domain: successful (same IP address)
• Cross domain: successful (with different IPs and ports, messages transfer between http and https)

• Data cannot be transmitted using form headers, form body, or query parameters by using postmessage.
• All data is transmitted through postmessage only.