The following is taken from
Agile PLM 9.3.2 New Features Quick Overview

The European regulation for Registration, Evaluation, Authorisation and Restriction of Chemical substances requires the weight based rollup of substances in products to determine compliance against the regulation. Prior to 9.3.2, Agile PLM Product Governance and Compliance did not have the ability to perform these weight based rollups. PG&C only was able to perform status rollups (compliant, non-compliant). The status rollups work well for regulations like ROHS, but cannot perform the complex calculations required to determine overall product mass percentages of substances required by REACH.

In 9.3.2, Agile PLM will create rolled up compositions based on specific rollup logic in a PL/SQL procedure run in the Agile PLM database and publish them back into the PG&C application. PL/SQL is used because it is more memory and processor efficient than Java for this use case. These summary compositions allow PG&C to evaluate compliance against a spec.

Design of the spec is up to customers in light of their legal interpretation of REACH and the amount of products they ship. This feature is intended to enable companies to Design for REACH, meaning to determine the risks of meeting REACH specifications by the design BOMs stored in PLM. If manufactured BOMs are very different from the As Designed BOMs, the Design for REACH calculations from Agile PLM could also be different than what was built.

This is a very complex new capability that is fully covered in a Transfer of Information recording. Some highlights of the features added to support Design for REACH are below.

• Import and export IPC 2.0 format

              o Agile PLM now supports the IPC 2.0 format, including multiple parts.

              o Existing classes IPC 1752-1 and IPC 1752-2 have new attributes to support IPC 2.0

• External Specifications and Database Rollup

             o A specification in Agile PLM can be flagged to be External.

             o New database capabilities have been added to extract the information needed for a weight based rollup into a set of documented staging tables in the database.

             o A documented PL/SQL procedure is added to perform the substance rollup and place the results into documented results tables.

             o At the completion of the rollup procedure, PG&C retrieves the information from the results tables and publishes them back into the application.

             o The PL/SQL procedure is documented in order to enable customers to extend the logic in case the out of the box rollup logic does not meet their legal interpretations.

             o The staging table is documented to enable potential extensions, like adding shipping projections in order to calculate potential shipments to different countries.

             o SDK and Web Services can be used to initiate the compliance determinations.

• Two new reports — the Exemptions Report and the External Rollup Report

I had a similar issue. The workaround I found was to leave through CSP (in WF admin) a dummy approver at each review (status type) with auto-promotion, and let the code remove this dummy approver just AFTER adding other approvers have been chosen by the code algorithm. The dummy approver might be a user-group, so it won’t catch an extra user license.

By default an index file for Fileload should contain in each row 6 values separetad by an attribute delimiter (which is a parameter in Fileload interface): ObjectType, PrimaryKey, SecondaryKey, Path/Filename, AttachType, Description.
In case you need to to populate additional attributes, you need to continue the row with pairs of attribute name and attribute value which are separated by different delimiter from the delimiter used for the rest of the Index row (= is the default attribute name-value separator).
For example, a row should look like:
ITEM|DMR16725400|00|file://YY022002/Share/Agile_Hammerhead/Agile_Hammerhead/Hammerhead%20Windchil%20PDF/452212876680_110m_1_approved.pdf|FILE|RING_FILE|Date01=20/06/2016

In latest Agile versions (9.3.4 for sure), there is a new preference called “Event Maximum Nested Levels Allowed”. Set it to 1 to avoid title block events loop. default value is 10.

In earlier Agile versions, the code may check the existing value before writing, and avoid writing if value already exist. That will allow the event to occur only twice and will avoid longer loops.

1. Prepare an index file. File names should be in server’s point of view. Use UNC (\server-nameshared-resource-pathname) for file names in order to eliminate drive mapping issues.

2. I prefer to run File Load from Java Client on application server rather than from a web client. It runs faster. In addition, Java client uses your windows login credentials, while web client uses the application service credentials, which are usually limited to local machine by system account. So files can be retained on network and there is NO need to copy them to a temporary location on server machine.

3. Set ‘Number Of Dedicated Threads’ to be more than 1, but less than the number of the machine CPU’s processors. It doubles the speed of file load.

4. Last tip: be aware not to hit ‘OK’ when file load ends, since it will start over. Hit ‘Close’ as it finish.

It is unclear within your document if rev 50f for item 003208 is the latest rev for this item.
where used tab shows direct parents that their latest released revision includes the item.
In Agile 9.3.x there is additional sub-tab for pending changes where used, means that it shows direct parents that their pending revision includes the item.
You can use advanced search type ‘Where-used One Level All Released Revisions” to find parents that had the item in a previous released revisions.

It is likely that transfer authority was done with parameter ‘All changes during the time period”, which means that authority will not be transfer for changes that required the approval before the time period defined by transfer authority record.

Does 50f is the LATEST released revision for item 003208?

There is no limit for number of affected items in a single change (which might be documnets in Document Change Order), although the best practice is to keep it lower than 250-300 affected items per change.
If you are using an older Agile version with ChangeCast module – too many affected items might create performance issue or cause the ChangeCast service to fail.

Hello Matan,

Agile Security Guide (soure: Agile Documentation) has an overview chapter and some best practices and recommendations about security.
Specifically regards LDAP, Oracle recommends communicating using LDAPS for the most secure deployment.

Tal